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 10/12/2017 09:29 PM, Dmitry V. Levin wrote:
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.
Right, I share your puzzlement.The only thing I think we could improve is that we should tag the first tag after a release branches with something like glibc-X.Y.9000, so that the git describe output is actually unique between the release branch and the next development branch (also, we should have update hooks which reject commits with multiple parents on the master branches).
I'd propose to add the following tags: 00cdcf5a4110f7ac68651f5662693c82f7bffaca glibc-2.26.9000 58557c229319a3b8d2eefdb62e7df95089eabe37 glibc-2.25.9000 e720d3d9fea2058adb3de2905f1a399ad3e812ff glibc-2.24.9000 c6f391dbf9b3b33e5bc0599dd96c40a0eff2f02b glibc-2.23.9000 1b15ff4810748abee11b949e6faa115f3f2d20f4 glibc-2.22.9000 d5a8b70560cf758218c13bef6f1dd93ce216424f glibc-2.21.9000 21c83793a223666b8cfe438d81615941896b355c glibc-2.20.9000 d5b396c1c89ed3026fc89bfcdd72b14d59972e45 glibc-2.19.9000 6c1fd795711bb510cffaab5ad2ab2739bb8db210 glibc-2.18.9000 c758a6861537815c759cba2018a3b1abb1943842 glibc-2.17.9000 75f0d3040a2c2de8842bfa7a09e11da1a73e17d0 glibc-2.16.9000The latter has also a glibc-2.16.0 tag, but I think that's misleading. The .9000 part (or any large number, really) confers that it's an artificial number, and it will sort correctly in most version number orderings.
Would these new tags break something for you? They won't change anything on the release branches, only on the master branch.
If you don't see a problem with that, I'm going to suggest this on a separate thread (it's too buried here to receive proper attention).
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |