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
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
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
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
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
> >
* 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)
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
fier of which specific
version is packaged. And it can be used to estimate of how up to date
the packaged version is, and to reliably check whether it has known
vulnerabilities and (when semver is used) whether it's compatible with
particular consumers.
> > So as you can see, even though there are no official
look at the git
submodule version (e.g. [1][2]); this is tedious as well.
But I don't see how a versioning scheme would significantly help.
> So as you can see, even though there are no official versioned releases,
> people have to invent and use these to refer to specific gnulib commit
>
://nvd.nist.gov/vuln/detail/CVE-2017-7476
https://nvd.nist.gov/vuln/detail/CVE-2018-17942
Note that it's impossible to match these against package versions due
to inconsistent versioning scheme.
So as you can see, even though there are no official versioned releases,
people have to invent an
10 matches
Mail list logo
