[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: Fri, 05 Jun 2020 08:15:57 -0400

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

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

  $ git describe

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

  $ git describe

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.

reply via email to

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