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

[km5vy Tom Russo]

I have created a pull request on github with the changes needed to documentation
to implement this simplified release process.

When you and Curt have reviewed it, please merge it and I'll move with actually
doing the point release.

Doing the point release this way is very little more than changing a version
number and tagging the repo, so it's very light weight.

I changed INSTALL to say that everyone needs to bootstrap.

I am NOT going to go through the uncountable infinity of distro-specific
install guides on the wiki to fix them all up, as they all have the same
information cut and pasted over and over again.  Maybe someone else can
take care of doing some of that?


On Thu, Oct 14, 2021 at 09:50:59AM -0500, we recorded a bogon-computron collision of the <godfreja at gmail.com> flavor, containing:
> 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
> >
> 
> 
> -- 
> "The problem with quotes on the Internet is that it is often difficult to
> verify their authenticity." - *Abraham Lincoln*

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