On Thu, Oct 14, 2021 at 04:53:15PM -0400, we recorded a bogon-computron collision of the <[email protected]> flavor, containing: > Another thumbs up to a 2.1.8 point release. > > It is also worth considering the github - zenodo integration, a github > project can be configured to archive a copy of a tagged release in zenodo, > complete with a DOI.
Hmmmm. Not sure that we really need "citable" Xastir releases. But it does give me some ideas for my day job... (https://github.com/Xyce) > On Thu, 14 Oct 2021 09:50:59 -0500 > Jason Godfrey <[email protected]> wrote: > > > Hello. > > > > I agree with a point release and simplifying the release process. > > > > 73 > > - Jason > > > > On Thu, Oct 14, 2021 at 9:47 AM Tom Russo <[email protected]> wrote: > > > > > 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 > > > > > > > > > > -- > Paul J. Morris > Biodiversity Informatics Manager > Museum of Comparative Zo??logy, Harvard University > [email protected] AA3SD PGP public key available > _______________________________________________ > Xastir-dev mailing list > [email protected] > http://xastir.org/mailman/listinfo/xastir-dev -- 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
