[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Versioned releases

From: Paul Smith
Subject: Re: Versioned releases
Date: Thu, 04 Jun 2020 15:46:21 -0400

On Thu, 2020-06-04 at 20:19 +0200, Bruno Haible wrote:
> Are you suggesting that every gnulib commit can be translated to a
> version number? There's 'git describe' which does that.
> Or are you suggesting that the Gnulib developers pick, say, every
> 100th Gnulib commit and assign it a version number? And how would
> that be useful, since the consumers upgrade when they like to?

What would be useful is if there were a "gnulib-version" module or
similar that was constructed when bootstrap was run and pulled in a new
suite of gnulib content, for example, based on the Git version perhaps.

Then applications could call a C function to return the gnulib version
as a string and include it in their --version output (if they wanted
to) and users could judge the "freshness" of the gnulib content.

For the distro packages, that take a snapshot of the Git repo: it would
be good if there were some way to have that snapshot contain hardcoded
version details from the Git, so that if apps bootstrapped from the
distro snapshot of gnulib they would get the correct hardcoded version.

I don't pretend to know too much about how all this works, including
how distros create gnulib packages, but this seems like something that
would be do-able and useful, and wouldn't need to involve any type of
"automatic versioning" of gnulib in the Git repo.

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.

I think the Git SHA is the single most critical element and must be
included.  However, it's not too informative unless the user has the
Git repo.

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]