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] _______________________________________________ Xastir-dev mailing list [email protected] http://xastir.org/mailman/listinfo/xastir-dev
