This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Clean up glibc version numbers in manual
On Tue, 21 Feb 2012, Roland McGrath wrote:
> > I've reverted that change, but I'd have thought it was the most obvious
> > part of the whole patch.
>
> Thanks for being flexible. I hope your misclassification of this
> particular change as "obvious" makes you a little more circumspect about
> doing things without allowing a reasonable period for discussion. We're
> not on the verge of a release or anything, and this was a change that did
> not interact with any other pending change. So it really does no harm to
> allow several days for the key people to respond.
Being on the verge of a release is a reason to be *more* circumspect about
committing things, not to do them in a hurry! I'd think that not being on
the verge of a release is more reason to get changes in quickly, on the
basis that other development can build on them and it's still easy to fix
problems that are found.
(But based on how that part of the manual was changed in the past, I think
what I did was in accordance with the previous semantics of giving details
for the last change of any kind, if someone remembered to change this bit
of the manual.)
> > Since it's already the case that there are several automatically generated
> > .texi files in the manual, I will now propose that we eliminate the
> > UPDATED information altogether, as I did for GCC in
> > <http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00206.html>, and generate
> > VERSION automatically so it is always the version number the manual came
> > with (and so the manual only claims to be for that version, not to be
> > *updated* for that version).
>
> That's a reasonable proposal worthy of consideration for changing what we
> put in the manual. But it's a departure from what that bit of the manual
> has meant in the past, and far, far away from the "obvious" category.
My belief is that what that bit of manual meant in the past is "when
someone last remembered to change that bit of manual or got reminded to do
so by a bug report" - not the last significant update, nor the last
trivial update (though after you last changed it, it did relate to the
last trivial update). Maybe once it meant something else, but not for a
long time.
Anyway, what do people think about that proposal - eliminating UPDATED and
generating VERSION automatically? (On the basis that a concrete patch
would then be posted for people to review the makefile changes involved.)
--
Joseph S. Myers
joseph@codesourcery.com