Re: Versioned releases

[Paul Smith]

On Thu, 2020-06-04 at 23:11 +0300, Dmitry Marakasov wrote:
> * Paul Smith (psmith@gnu.org) wrote:
> 
> > Regarding the format of the version:
> > 
> > First, semver is not right for gnulib.  The entire concept behind
> > semver and similar versioning schemes is to use a version string to
> > describe compatibility guarantees between different versions. 
> > That's (IMO) completely inappropriate for a source-only package
> > like gnulib.
> 
> Why, that's precisely what semver is useful and was designed for.
> It's MAJOR.MINOR.PATCH - if you break API, bump MAJOR, if you
> introduce new feature, bump MINOR, otherwise bump PATCH.

I'm not a gnulib developer, so I don't want to speak for them: maybe
they would like to make this attempt.  But IMO it's not appropriate for
gnulib.

During the development of gnulib there aren't discrete release points
where someone will stop and consider all the changes since the last
release, and assign some version to it as a whole.  To the extent that
such discrete points exist they are invented by distributions that
include gnulib as a package... not by the gnulib developers.

To follow semver, or a similar versioning scheme, would mean that EVERY
SINGLE COMMIT would have to change the version, because EVERY SINGLE
COMMIT makes some change, and anyone could do a Git pull of gnulib at
any instant and include it in their program, or in their distribution.

The only possibly workable option would be to have the first two
numbers in a semver be bumped by developers when they pushed changes
which they knew to change the API or add a feature, and leave the last
number to be automatically generated based on the number of Git commits
since the last version bump (since those commits can be assumed to be
bugfixes only).

However, I doubt this is reasonable either.  First, even only
considering the first two semver values it would add a lot of overhead
and effort to the development process to consider and get right these
version bumps with every push to the repository.

Second, remember gnulib is not a monolithic entity: it's a collection
of 1,200 or so discrete "utilities" (and counting...), most of which
are just one or two files.  Do we say that the version of gnulib should
change every time ANY ONE of those hundreds of utilities had a new
feature or a change to their API?

Suppose Bruno pushes a new module (second number bump), then the next
day realizes it has a problem that needs the API to change (first
number bump).  Then an hour later he realizes there's another problem
with the API (another first number bump).  Etc.  Just because the API
version bumped doesn't tell you anything very interesting when it could
be any one of >1000 different utilities whose API was changed, for any
number of reasons.

> So as a consumer I may just require e.g. version >=1.2.3 <2, and
> expect it to be API-compatible and have all the features my code
> requires.

That isn't how gnulib is intended to be used.

> > My recommendation would be to automatically add a tag once a month
> > (say) to the gnulib Git repo with the date, and then use the "git
> > describe" output as the version.  This gives an easily-comparable
> > version string with all the info needed.
> 
> This complicates the format, as SHAs are never appropriate in the
> verions, for they are not monotonic and alphabetic characters are not
> compatible with all package managers. Someone may include them, some
> may omit them, and we'll end up with incompatible versioning schemes
> again.

IMO the idea of being able to learn anything from a gnulib version that
is more informative than, "this one contains more recent commits than
that one" is not feasible.

But I think that "this one contains more recent commits than that one"
_IS_ a very useful and desirable metric and speaking as a gnlib user I
hope we can find a relatively painless way to incorporate it.