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