Point releases for the GNU C Library

The glibc 2.26 release is generally only found in relatively fast-moving distributions at this point. For most users, 2.26 has been without problems, but that is not true for everybody. There have been a few significant regressions in this release that have required fixes; one of those was seen as important enough that the question of creating a 2.26.1 point release was raised. Romain Naour subsequently brought that discussion to the libc-alpha mailing list. Having a point release containing important fixes would be helpful to downstream distributors that want to incorporate those fixes, he said.

Like many projects, glibc fixes bugs first in its repository trunk — the branch that will eventually become 2.27 at the moment. The project does not make point releases, but that does not mean it leaves users of its previous releases entirely out in the cold. A branch in the repository is created for each release and, at the discretion of the manager for that particular release, important fixes are backported and added to that "maintenance branch" post-release. So distributors have a stream of nicely backported fixes for each release; what they don't have are point releases that contain a well-defined set of those fixes.

Some glibc developers strongly question the need for those releases. Creating a formal release is a significant amount of work, involving running tests, writing release notes, creating tarballs, etc. A major release is an indication that a point of stability has been reached and the code is in a state that is meant to be ready for production use. The maintenance branches, instead, are meant to always be in such a state. A point release would just be an arbitrary marker placed in the stream of maintenance patches, so one might as well just use "git describe" output to name that point. Thus, Florian Weimer observed that "the difference between glibc 2.26.5 and glibc 2.26-40 seems rather minor to me". He suggested that all that was really needed was a special tag at the beginning of each release branch that would show up in the output of a git describe command.

Representatives from a few distributions made it clear that they felt differently, though. Arjan van de Ven noted that a release tag helps distributors and users to know what is in a given package:

Andreas Huettel, representing Gentoo, agreed that there is value in having a well-known reference point. Yann Morin, of Buildroot, also agreed, noting that these reference points would be especially helpful to smaller distributors that do not have the bandwidth to follow the maintenance branch closely.

In response to the discussion, Siddhesh Poyarekar, the 2.26 release manager, said that he would probably do a 2.26.1 release in the near future. He explicitly did not commit to doing any point releases beyond that one, though. He also said that a point release, if he creates one, should not be seen as a commitment by the project as a whole to create such releases in the future. Carlos O'Donell stressed that last point, saying that "we don't want to set a precedent that the glibc release manager is always going to do a point release".

O'Donell went on to say that the glibc community in general lacks the resources needed to put together regular point releases. But, he said, downstream distributors might be able to create those releases with "a little help" from the glibc developers. He has promised a proposal describing how that cooperation might work, but it has not been posted as of this writing. He has, however, come out in favor of Weimer's special-tag proposal.

One might be tempted to conclude from this discussion that the need for our release-based software-distribution conventions is waning over time. When every point in a project's history already has a unique name (its Git commit ID), and when growing use of continuous-integration techniques leads to a situation where repository contents can be run at arbitrary points with relatively high confidence, perhaps the release rigmarole can be done away with, at least for point releases. But anybody thinking so should consider the ways in which glibc is unique.

The C library sits between most applications and the kernel. While many users install their own application releases, and a certain number are happy to replace the kernel, it is relatively rare to install a new glibc release. The glibc project moves slowly, new releases tend to have little in the way of exciting new features, and glibc is a rather difficult component to replace so, for the most part, whatever is on the system is good enough for most users. Few people feel the need to be running whatever the latest release is, so they tend to care rather less about glibc point releases than about releases of other components in their systems.

Distributors, instead, pay a lot of attention to the C library. Once they have installed a specific version, they are likely to scrutinize any follow-on patches and will not necessarily accept every change that appears in the glibc maintenance branch. So some distributors, at least, may see little value in point releases for glibc, while others (the smaller ones, perhaps) see some use there.

In other words, glibc may be unique in its relative lack of need for regular point releases; the rest of the community is unlikely to want to trade in concise version numbers for random-seeming commit IDs. But, even in the corner of the community where glibc lives, some users would rather have the occasional well-defined point release, with the result that glibc 2.26.1 may make an appearance in the near future.