[Xastir] [russo at bogodyn.org: [Xastir-dev] New release coming up soon, old release "regenerated" on Github, call for discussion]

Fri Feb 9 12:46:26 PST 2018

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 <russo at bogodyn.org> -----

Date: Wed, 7 Feb 2018 11:52:48 -0700
From: Tom Russo <russo at bogodyn.org>
To: xastir-dev at 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-dev at 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]