[Xastir-dev] Maybe it's time for a 2.1.8 release?

[Tom Russo]

Gang:

It's been over a year since our last Xastir release, and there has been very
little development since then -- mostly minor tweaks to the build system
necessary to keep Xastir building as compilers, libraries, and 
autoconf/automake keep dropping support for old things we used to do.

We just got a pull request to fix a dumb autoconf issue that broke Xastir
builds on gentoo when using the very latest autoconf/automake.  It was
utterly trivial to fix.

Most of these things are hacks that are already being addressed by package
maintainers using local patches, but we've addressed them in the base package
so it would simplify their processes if we just pushed out a new point release.
The gcc10 fixes we did a while back were of this ilk, and our pushing out
the 2.1.6 release helped get those changes to everyone instead of every OS
having to patch them up themselves.

It is also the case that some distros and non-linux operating systems don't
update Xastir except when we do official releases, so pushing out a new release
would help those OSen stay up to date.

We've had a "2.2.0" project on the github page for a really long time and
there has been no motion on the 6 "to do" or "in progress" items needed to call
that release done.  So I do not propose we call our next release 2.2.0, but
just 2.1.8, capturing the state as it is right now.

Does anyone have any objections to making such a release in short order?

Also:  our current "release process" is a little antiquated and is designed
to minimize the "surprise" when transitioning from our old SourceForge/CVS
release process to our new github.  The big one is that we do this weird
thing so that the tarballs created for our releases are "pre-bootstrapped"
so they're ready to go upon being downloaded instead of requiring the user 
to run bootstrap.

It's years now since we moved to git, and maintaining clunky release processes
to accomodate those who only know CVS seems long past its sell-by date.

There are downsides to this clunky release approach, almost all on my end --- 
it makes it much harder to create a release, because we have to create a 
branch, do funky things on that branch to make bootstrap artifacts no longer 
ignored, commit those things, and then tag the end of the branch as the 
release (and the tag can then be used at github to create the tarballs for the 
release automatically).

Doing this means our "release branch" is a dead end and is never merged back
onto master, and our release tag is not reachable in git history from master,
meaning "git describe" output is almost useless.

I propose we discontinue this handholding approach that serves only to let
downloaders skip exactly one step of the build process (the bootstrap, which
creates configure and all the Makefile.in files), and go to one where the
tarballs are literally just a snapshot out of the git repo, and built exactly
the same way (bootstrap, configure, make).

Changing this means simplifying the build instructions to remove "if you're
downloading a tarball, do this, if you're cloning git, do that" conditionals
and replace them with "do that".  But in the long run it will make the
process simpler and might make deciding to make point releases less weighty.

It also means changing the document that describes how to do the release in
excruciating detail (README.developers.md).  I propose removing the 
instructions for how to do "development snapshots", too, since this hasn't 
been done in many years and is clearly no longer needed.

If we agree that doing a point release makes sense, I also call on all to 
take a quick look and see if there are any things that need immediate update 
(for example, get-NWSdata is frequently behind the times and references 
outdated files --- anyone checked recently whether it needs an update?).  It 
would be good to get those done before pushing out a point release.

-- 
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]