Re: Versioned releases

[Paul Smith]

On Thu, 2020-06-04 at 23:29 +0200, Bruno Haible wrote:
> I disagree on this one. It would make people think that the Nth
> commit, or the Monday commit, or whatever, is preferred over the
> other commits.  Which it really isn't - there may be a regression fix
> coming in just the next day.

I'm not sure about that.  A tag which is just the date is pretty
clearly nothing more than that: a tag which is the date.  I don't think
anyone will somehow believe that it means more than it is.

Plenty of systems out there do similar things.

> In summary:
>   * The date (first line of ChangeLog) is a good version indicator.
>   * If someone doesn't like dates, for whatever reason, they can use
>     'git describe'.

IMO 'git describe' is less useful without some type of tagging regimen.

Even tagging once a year would be helpful.

This is today:

  $ git describe
  v0.1-3536-gd50852525

??  If we added a tag "2020" at the beginning of the year we'd get:

  $ git describe
  2020-427-gd50852525

A tag like "202006" the beginning of the month would be:

  $ git describe
  202006-11-gd50852525


However it's done, my main hope is that gnulib provide some kind of
module which does this version detection and generation for you, and
builds that into its scripting so it's automatic, rather than everyone
reinventing it (possibly slightly differently) for themselves.

For example when I run bootstrap against a Git repo, it would run "git
describe" and put the results into some gnulib version string in the
files copied into my workspace.

And there could be an "extract a static workspace" script that would do
the same type of thing for an entire gnulib copy, that distributions
(if they really wanted to ship a "gnulib" package) could run.