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

[Jason Godfrey]

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*