Re: Versioned releases

2020-06-05 Thread 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

Re: Versioned releases

2020-06-04 Thread Bruno Haible
Bernhard Voelker wrote: > Well, the projects using gnulib (via git submodule) could at least generate > the 'git describe' value into their NEWS file or other documentation. Some packages do this already. The latest GNU Bison release announcement [1], for example: "This release was bootstrapped

Re: Versioned releases

2020-06-04 Thread Bernhard Voelker
On 2020-06-04 20:19, Bruno Haible wrote: > Indeed e.g. Debian has a gnulib "package": > https://packages.debian.org/sid/all/gnulib/filelist > > But I think it's a red herring, since basically no one is using gnulib > this way. I agree, it's not really useful: e.g. I'm using openSUSE:Tumbleweed,

Re: Versioned releases

2020-06-04 Thread 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

Re: Versioned releases

2020-06-04 Thread Paul Smith
On Thu, 2020-06-04 at 23:11 +0300, Dmitry Marakasov wrote: > * Paul Smith (psm...@gnu.org) wrote: > > > 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 > > descri

Re: Versioned releases

2020-06-04 Thread Dmitry Marakasov
* Paul Smith (psm...@gnu.org) wrote: > 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) c

Re: Versioned releases

2020-06-04 Thread Paul Smith
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

Re: Versioned releases

2020-06-04 Thread Dmitry Marakasov
* Bruno Haible (br...@clisp.org) wrote: > > Despite that gnulib homepage says "Gnulib does not make releases. > > It is intended to be used at the source level." gnulib is in fact > > packaged in quite a lot of distributions: > > > > https://repology.org/project/gnulib/versions > > Indeed e.g. D

Re: Versioned releases

2020-06-04 Thread Bruno Haible
Hi Dmitry, > Despite that gnulib homepage says "Gnulib does not make releases. > It is intended to be used at the source level." gnulib is in fact > packaged in quite a lot of distributions: > > https://repology.org/project/gnulib/versions Indeed e.g. Debian has a gnulib "package": https://pac