Re: Versioned releases

[Bruno Haible]

Hi Dmitry,

> My claim only covers standalone distribution of gnulib. I don't want
> to dig into the reasons for why upstream forces bundling and why
> downstream don't follow it anyway, but the sole fact that it's packaged
> standalone in so many distribution speaks for itself of that this way of
> distribution is a necessity.

I don't think so. This way of distribution is a misunderstanding.

Every developer nowadays is used to doing 'git clone' here and there;
there are even more and more people who prefer the hassles of building a
package from a git checkout to the sailing trip of building a tarball.

> With standalone distribuition there's no way to peek into git history
> or some source files, but there's a clear identifier of which specific
> version is packaged.

Yes. As I said, the first line of the ChangeLog is the best identifier.

> > 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?
> 
> I would suggest using proper semver.

semver is not a good philosophy for gnulib, because different packages
use different gnulib modules. This week we made an incompatible change
to the 'read-file' module; but the vast majority of the packages will
not be impacted because they don't use this module. Therefore bumping
a version number is not really meaningful.

> But dumb tagging every nth
> commit, or weekly or so would definitely be better than nothing

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.

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'.

Bruno