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.
-Paul 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
