[Xastir-dev] New release coming up soon, old release "regenerated" on Github, call for discussion

[Tom Russo]

I think I am days away from pushing out an Xastir 2.1.0 stable release, 
which will pretty much be exactly the code that's at the head of master
right now.

To test out the release mechanism on github, I've gone ahead and created
a "new" Xastir 2.0.8 release branch (branched from the xastir208 tag that
was used for the SourceForge stable release), bootstrapped it, pushed it to
github, tagged it with "Xastir-Release-2.0.8", and told GitHub to call it
a release.  I've done this so that package maintainers who were previously
pulling the tarball for 2.0.8 from sourceforge could pull an equivalent
tarball from github instead and revise their package build procedure, just to 
get ready for the next release.

The tarball for a ready-to-build version 2.0.8 of Xastir could be downloaded
just by wgetting 

   https://github.com/Xastir/Xastir/archive/Xastir-Release-2.0.8.tar.gz 

a Zip file could be gotten as:

   https://github.com/Xastir/Xastir/archive/Xastir-Release-2.0.8.zip

One thing to note:  These files unpack into "Xastir-Xastir-Release-2.0.8,"
an artifact of how Github creates tarballs.  I put "Xastir-" into the tag
name so that when the release tarball is downloaded it wouldn't just be
called "Release-2.0.8", but github has helpfully bundled it up with the
project name prepended.  This should not be a problem, and I've seen other
projects do their releases this way.  But it does mean that the extracted
files have an extra "Xastir-" in the top-level directory name.

One can also view the "latest" release at 
  https://github.com/Xastir/Xastir/releases/latest
and all releases at:
  https://github.com/Xastir/Xastir/releases

There are other, more obscure methods to get at it.  Some automated package
systems may use those methods (looking at you, FreeBSD), in which case one
would make sure to use "Xastir" as the account name, "Xastir" as the package
name, "Xastir-Release-" as the distribution prefix and "2.0.8" as the version
number.

When the 2.1.0 release happens, the same thing will apply with only the 
version number changed.

If you're a package maintainer for any OS, you might start looking into how
you have to change your package build process to access the Github release
tarballs instead of SourceForge.

If you have push access to the Xastir repo (so far that means only you, Curt),
never, ever, ever merge one of these release branches back to the master
branch --- they contain modified .gitignore files so that bootstrap artifacts
are not ignored, and also contain the bootstrap artifacts so that checking
out the branch (or downloading a tarball) gives you a complete ready-to-build 
directory, just like the old tarballs did.

If you have heartache with how I've done this 2.0.8 recreation and would hate
to see it perpetuate into all future releases, please let me know so I can
rethink the procedure.  But I think this is a pretty close simulation of how
release tarballs on sourceforge were, and should be an easy way for folks to
grab stable releases without using git.

-- 
Tom Russo    KM5VY
Tijeras, NM  

 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]