Re: Autoconf, snapshot builds, git-version-gen, and groff's version number

[Ingo Schwarze]

Hi Branden,

G. Branden Robinson wrote on Fri, May 27, 2022 at 01:29:11PM -0500:

> Does anyone have any ideas for how we might surmount this issue?

Certainly not by piling yet more overengineering on top of all the
overengineering we already have.  We don't need ten different ways
to download and build groff.

Having one way that is simple and reliable is better.

For releases, tell people to download tarballs.  They already work
as intended, nothing to fix there.

If people want to play with unreleased code, tell them to use git(1).
It provides all kinds of useful functionality for that purpose (and
more), for example switching to any desired commit.  Supporting
neither-fish-nor-fowl stuff is not only pointless but harmful because
it wastes development time and introduces new opportunities for bugs.

I already consider "git describe", "git-version-gen" and anything
related to it as overengineering.  When using a release, it is not
needed at all.  When an OS packager packages a release but applies
a minimal set of OS-specific patches (which is very common and
reasonable), it doesn't help at all because those patches are not
in the groff git repo, so if the packaging system requires modifying
the version number (usually by appending to it), packagers usually
do that using tools specific to their packaging system.

If somebody compiles from arbitrary git commits, *no versioning
is needed* because such stuff is either needed only for development
purposes or purely private.  Stuff compiled from arbitrary git
commits will never be used in packaging systems nor be distributed
to end users.

So this whole git-version-gen complexity solves an imaginary problem
that does not exist in the first place.  Its only benefits are being
excessively complex and creating yet more imaginary follow-up problems
like this one.

Yours,
  Ingo