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 Thu, Oct 12, 2017 at 09:59:09PM +0200, Florian Weimer wrote: > 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 The first commit after glibc-2.17 is 2c8bfe7d6f22c4a599894846bf1715d93b295f53. > 75f0d3040a2c2de8842bfa7a09e11da1a73e17d0 glibc-2.16.9000 > > The latter has also a glibc-2.16.0 tag, but I think that's misleading. That's because glibc-2.16 was incomplete and glibc-2.16.0 is the real tag of 2.16 release. The first commit after 2.16 is the one tagged as glibc-2.16-ports-merge. > 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. These new tags are fine, thanks! -- 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] |