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

Thu Oct 14 18:46:25 PDT 2021

On Thu, 14 Oct 2021 19:09:25 -0600
Tom Russo <russo at bogodyn.org> wrote:

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

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

-- 
Paul J. Morris
Biodiversity Informatics Manager
Museum of Comparative Zoölogy, Harvard University
mole at morris.net  AA3SD  PGP public key available