Gang: On Wednesday, I sent the message below to the Xastir-dev mailing list, presuming that anyone who's a package maintainer for Xastir on some Linux (or other) distribution certainly must already be on the developers' mailing list. I just noticed that some folks who post here and say they maintain Xastir packages are NOT on that list.
The short story: I am preparing to do our first real release since Xastir moved from SourceForge CVS to Github Git. I plan to do it sometime tomorrow. It will be Xastir 2.1.0. It is largely a maintenance release, but does have some good new stuff in it including IPv6 support, a new script to support WXNOW.TXT weather stations, updated DBFAWK files for NWS shapefiles, AIS and ADS-B support, support for proportional fonts in map labels, unbroken compressed weather alerts, etc. You know, everything that's in the Git repo on the master branch since 2.0.8 was released. To prepare for the next release, I tested out a release process by re-releasing Xastir 2.0.8 (from July 2016) as a Github release, since the previous release was done on SourceForge. My intent was that people who maintain Xastir packages could use it to prep their packaging process to pull from Github instead of SourceForge --- the result should be an Xastir build that is identical to what you were doing for Xastir 2.0.8 prior to the git move, but using the new package source and tarball structure. If you are a package maintainer for Xastir, I ask: 1) Please join xastir-dev, so you can get stuff like this a little earlier. xastir-dev is supposed to be where the developers discuss technical aspects of Xastir development, but it's also where we talk about pushing out releases (every couple of years, whether we need one or not). 2) Please update your package building process so it can work with the new github release distribution process, as described below. 3) If your package is anything older than 2.0.8, please, please, please update it. I am seeing signs that some package systems may still have 2.0.6, 2.0.4, or maybe even 2.0.0 in them (judging from the number of connections to APRS-IS servers from programs that old). If you are not a package maintainer, but do USE a packaged version of Xastir, and the maintainer of that package is not subscribed to this list already, I ask you: 1) Please contact the package maintainer and ask him or her to join xastir-dev. 2) Forward this email to him or her. If you are NOT a package maintainer for Xastir on some package management system, but have ever created an "Installation Notes" page on the Xastir wiki, I ask that you go through your old installation notes and make sure that none of them reference sourceforge source code tarballs or sourceforge CVS. There are just too many of those Installation Notes for me to go through them all myself, and many of them pertain to OS's that I have no way of testing out. If you are neither a package maintainer nor a wiki page author, and you want to help out, I ask that you take a moment to read over some of the README.* files in Xastir's source tree and let us know which ones have unbelievably outdated information in them that should be update. I have been picking through them and trying to bring them up to date, but there are so many that my eyes are starting to bleed. At this point, I have to stop and just go ahead and push out what we have as of tomorrow (afternoonish). BTW, if anyone has ever built Xastir on Mac OS X using Homebrew as the package manager, it would be great to have an Installation Note for it. The current OS X install notes pertain only to Fink and MacPorts (and I have no idea whether they still work). ----- Forwarded message from Tom Russo <ru...@bogodyn.org> ----- Date: Wed, 7 Feb 2018 11:52:48 -0700 From: Tom Russo <ru...@bogodyn.org> To: xastir-...@xastir.org Subject: [Xastir-dev] New release coming up soon, old release "regenerated" on Github, call for discussion 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 xastir-...@lists.xastir.org http://xastir.org/mailman/listinfo/xastir-dev ----- End forwarded message ----- -- 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 mailing list Xastir@lists.xastir.org http://xastir.org/mailman/listinfo/xastir