On Thu, 14 Oct 2021 19:09:25 -0600 Tom Russo <[email protected]> wrote:
> 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. Not a big selling point in this community, but the automated archiving of copies of the code base at relases may be. > > But it does give me some ideas for my day job... > (https://github.com/Xyce) Using it on several in mine, got pointed at it by some data science folks. -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 > -- 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
