This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Fri, Sep 29, 2017 at 05:26:23PM -0700, Paul Eggert wrote: > Romain Naour wrote: > > Maybe a middle ground is that a tag is pushed to the repository, just to > > identify a specific sha1 as "this is 2.26.1". This is relatively lightweight (a > > signed tag) and gives downstream users that need it a clear identification of a > > blessed version. > That "blessing" would be problematic. How can we be expected to "bless" any > particular commit unless we've checked it? And that checking will take some > work, work that will slow us down on other things. > > Instead of blessing, how about using the output of something like the following > shell command to generate the version number? > > git describe --match 'glibc-*' --abbrev=7 --dirty > > This will generate a string that identifies the commit but is shorter and easier > to read than an SHA hash, and so is more likely to give users that warm and > fuzzy feeling. On my glibc repository right now, for example, it generates: > > glibc-2.26-415-g4d3693e > > which means there have been 415 commits since 2.26, and the latest commit can be > abbreviated 4d3693e. A similar (but shorter) version-numbering scheme is used by > GNU Coreutils and other GNU packages when between releases, and Gnulib has a > script build-aux/git-version-gen that can generate it. We (ALT) adopted this scheme for most of the packages that are built from git snapshots, and I think this is the way to go. git is available for more than 12 years, why some distro builders need an officially released tarball made from release/2.26/master branch that would be no better than current glibc-2.26-58-gf725563 (aka 2.26.0.58.f725563 in git-version-gen's notation) is beyond my understanding. It would be a different story if somebody volunteered to do a proper release testing of point releases similar to what's currently done or releases, see e.g. https://sourceware.org/glibc/wiki/Release/2.26 Are those projects that want point release tarballs are ready to do a proper pre-release testing? If yes, then it makes sense to do point releases. -- ldv
Attachment:
signature.asc
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |