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]

Re: Glibc stable release process (Glibc 2.26.1)


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]