[Xastir-dev] Long past time for a new release

[Tom Russo]

We have not had an Xastir release since 2.0.8, prior to our move off of 
SourceForge and onto github.  

That means that any package managers out there are providing code that's 
nearly two years old, since most won't generate new packages without release 
tarballs (and many won't do it even *with* new tarballs, but I digress).  And
those old packages probably all have READMEs and other documentation that
points people to SourceForge.

I'm thinking we ought to get to a nice stable place (maybe after all the IPv6
stuff is shaken out) and tag a new 2.1.0 release sometime soon.  There have
been a few notable improvements lately, and we should share them with people
who aren't going to get all gitted up.

I've already gone through the code and updated all the copyright dates, and
cleaned up some documentation files in preparation for that sort of thing.

Typically, a release under SourceForge meant Curt generated a post-boostrap.sh
tarball of the code (so it includes configure and all the Makefile.ins), then
just uploaded it.

Generally, a release on Github is just a tag that makes it show up on the
Releases tab, and then when a user clicks the ".zip" or ".tar.gz" link, github 
just zips or tars that repository state for them.  It is possible to upload 
additional binary files to associate with release as well, but that's not what 
we want here -- we actually want the tarballs to be ready to configure/make, 
so the source tarball needs additional files.

While it greatly simplifies the process of calling a repo state "released," 
that approach to release tarball generation makes the post-bootstrap.sh thing 
a little tricky.  It has been proposed here before that we do it via a release 
branch, where we commit and push the bootstrap artifacts to the release branch,
then just tag the head of that as the release, leaving master without those 
files.  In that way, the release branch could just be checked out and built 
(without running bootstrap), as could any code taken out of a tarball of the 
release branch.

I think I like that idea, and intend to make the 2.1.0 release like 
that if there are no objections to the approach.

Anyone holding on to new code they'd like to see in the 2.1.0 release?  
Is Dan's experience with IPv6 addressing something that Jason is going to 
have to fix, and so should block doing the 2.1.0 release for a while?

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
 echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m]