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

[Paul J. Morris]

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