Re: versioning

[Roland McGrath <roland at redhat dot com>]

I don't like this plan.  I would like to fully address all the concerns
that motivated it, but I think we can find different and better ways to
accomplish that.  I hope you will take the time to help me understand fully.

It is indeed useful to have manually designated releases, "formal" releases
if you like.  The reason that makes these desireable for any piece of
software is that making such a release is the way that we, the maintainers,
announce that the state of the code is "good and stable"--something people
can expect to upgrade to without unknown new pain, and that they might want
to upgrade to if they are going to put off the next upgrade for some period
of time beyond when the very next usable thing can be had.  It is not
really the case that the development code is "always good with rare, brief
exceptions"--it is often a moving target for significant periods in the
natural course of development and maintenance (a few weeks of regex
instability here, a few weeks of dynamic linker instability there) and
there is no reason it shouldn't be.  

Moreover, in the case of glibc there is a more compelling reason to want
clearly distinguished releases.  That is, these are the points of API/ABI
stability.  There is no reason we should not add new symbols or new
versions of existing symbols with the relative freedom that we do now.
During the course of development, we may add a new interface and then
decide to change its details a week or three later.  We have always made
clear that new and changed interfaces are subject to continual change
between releases.  It should remain so.  Bottom line, to me what a "formal"
glibc release means is a closing of the given GLIBC_x.y.z version set and a
promise to provide binary compatibility for correct programs built from
that point forward.  I presume that the reasons why it's bad for us, the
glibc maintainers, to potentially support a proliferation of symbol
versions are obvious, both the technical ones (version name explosion
slowing searches and inflating binaries, symbol table and text inflation
adding overhead) and the practical ones (cruft in the sources, future
maintenance burden of compatibility versions).

For these reasons, I object to abandoning formal glibc releases.  
Now I would like to explore the root issues that motivated Ulrich's plan.

I quite agree that the old plan of making official test releases, waiting,
and declaring them tested and good enough before each official release, is
not working any more and has not been working well for quite some time.
The situation for some time now has been that some given state of
development from cvs is taken as the true basis for the whole-system
distribution versions of glibc such as Debian's and Fedora/Red Hat's called
2.3.2-NN and so forth.  The given snapshot chosen by each distribution's
glibc package maintainers is what actually receives a lot of testing and
gets deployed.  Overall, this is a perfectly fine state of affairs and
exactly the way we want to get leverage from distribution-specific efforts.
The problem is that this has not been feeding back into the mainline
development/release activities in any orderly or well-understood way.

I think the situation we want is that a formal glibc release is a statement
after the fact.  That is, when a given snapshot state has gotten good
testing via its use in whole system distributions and been declared stable
in practice, then we christen that state with a release number.  That
should be a wholly painless and easy process for any authorized maintainer
to do, i.e. running a script that goes quickly and maybe doing a GPG
signature.  There is no reason this shouldn't happen frequently, at least a
hell of a lot more frequently than glibc releases have been heretofore.

What I would like to see is a regular system of snapshots.  This means that
GLIBC_i.j.k.yyyymmdd means exactly the same set of sources to everyone.
(That's easy to do with tags or just with a clear specification of 0:00 UTC
on each YYYY/MM/DD as the moment of repository state we're referring to.)
tarballs (whether with or without CVS/ subdirs) are useful for some people,
and it's not hard to make them available automatically, so we should do so.
It is my hope that the glibc packages in development versions of each
distribution can be based on canonical dated snapshots with vastly smaller
numbers of additional distribution-specific patches than what we see now.

I would like to do whatever needs to be done to make the physical details
of cutting a release as trivial and painless as possible.  None of this
automation should be at all hard.  (We can start with dumping the "make dist"
cruft and using simple scripts around cvs operations to make tarballs.)
Whenever there is consensus that GLIBC_i.j.k.yyyymmdd is a stable point,
it can be retroactively declared GLIBC_i.j.(k+1), diddled, tagged, and
released with the push of a button.

If there are root motivations other than the ones that I have raised,
please describe them explicitly.  Once I'm sure that all these are on the
table, I would be happy to discuss how the suggestions I have made here do
or don't address all the important issues.


Thanks,
Roland