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

Thu Oct 14 18:09:25 PDT 2021

On Thu, Oct 14, 2021 at 04:53:15PM -0400, we recorded a bogon-computron collision of the <mole at morris.net> 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 <godfreja at gmail.com> 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 <russo at bogodyn.org> 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
> > > Xastir-dev at lists.xastir.org
> > > http://xastir.org/mailman/listinfo/xastir-dev
> > >  
> > 
> > 
> 
> 
> -- 
> Paul J. Morris
> Biodiversity Informatics Manager
> Museum of Comparative Zo??logy, Harvard University
> mole at morris.net  AA3SD  PGP public key available
> _______________________________________________
> Xastir-dev mailing list
> Xastir-dev at lists.xastir.org
> 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]