On Mon, 25 Feb 2002, David S. Miller wrote:
> From: Matthias Andree <matthias.andree@stud.uni-dortmund.de>
> Date: Tue, 26 Feb 2002 00:01:56 +0100
>
> > And how should EXTRAVERSION be accommodated?
>
> sed/perl/awk -- a short five-liner "bless-rc-to-final" script should do.
>
> Ummm... no.
>
> This whole conversation exists because "Deleting the EXTRAVERSION
> setting from linux/Makefile" then making new diffs/tars was screwed
> up. Doing it with a script isn't going to help this kind of problem.
>
> I repeat: it isn't a "release candidate" if it will not match preciely
> what the final tarball/patches contains. Anything else opens up the
> possibility for errors to be made.
I'd think that running a script to "upgrade" 2.4.N-rcM to 2.4.N by just
unpacking that latest rc tarball, editing the Makefile and tarring
things up again, should be safe enough, and if it doesn't allow for
operator interference, especially so.
I'd rather violate the "it's not a release candidate if it changes to
the final release" than have differing versions with the same tag
around, which would be a support nightmare. "Does the person who
reported this bug run the release candidate or the final version?" That
question is hard to answer if you cannot ask for uname -r, but end up
asking for the MD5sum of that tarball, and that still does not account
for patches, patches missed and patches applied -- Would you want that?
I would not.
I think that the coupling between tag and corresponding code should be
tighter than that of the release candidate to the release, but I don't
decide on this issue, Marcelo does.
-- Matthias AndreeGPG encrypted mail welcome, unless it's unsolicited commercial email. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 28 2002 - 21:00:20 EST