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
