| |||||||||||||
|
| |||||||||||||
Hobby HorseHobby HorsePosted Sep 5, 2008 15:55 UTC (Fri) by Baylink (subscriber, #755)In reply to: RFC: adding a 'version' flag process to kernel development in a non-destructive manner by kirkengaard Parent article: Linux 3.0?
<sigh>
Version numbers *mean* something to people, as much as Linus would like to assume they don't.
Lots of people have been numbering lots of software for a long, long time, and the conventions that have sprung up around that happened because they were useful, both to people who assign numbers, and because they were useful to people who need to read them.
It's just like the recent trend of renumbering Interstate exits to match the mile markers: changing the convention provides no *new* information (there were mile markers along the side of the road already, thank-you-very-much) and deprives you of *useful* information that there is now no way to get (did I miss the last Sarasota exit, honey? Hell if I know, dear).
At their base, version numbers are a contract between a user who reports them, and a tech support person who has to know what you're running, and for that purpose, yes, anything will do.
But people, including end users as well as release managers for distributions, make other conventional assumptions about release numbers, to help them make decisions about what they should do in upgrade situations, and breaking those assumptions seems fraught with peril.
Not to mention that if RPM can't manage to figure out that 1.0.0rc5 => 1.0.0 is an *upgrade*, and shouldn't require --force... leading a project to have to name its first production release 1.0.1, how in *hell* should we expect it to handle whatever whacky scheme it is that Linus has in his bikeshed?
No, I don't often think Linus is wrong, and I'm willing to be convinced otherwise, but this is one of those times.
(Log in to post comments)
Hobby Horse Posted Sep 7, 2008 21:13 UTC (Sun) by kirkengaard (subscriber, #15022) [Link]
Please explain the breakage you imply to the natural upgrade assumptions, making reference to your parent post. Removing cruft *is* an upgrade, AFAICT, and I said nothing that should imply backwards progress linked to forwards numbers. 3.0 will mean something, whatever the process that is linked to that number happens to be. Ripping out cruft is simply the discussed process for calling the 3.0 flag this time.
Also, didn't I explicitly reject reusing the major revision flag for this exact reason?
And, you're misusing bike-shed; the canonical usage which has been followed above is as an object, not a container, and the reference is to what color we'll paint it. Absent that allusion, what are you talking about WRT Linus, numbering, and "wacky schemes" that would violate incremental version-numbering?
[OT] mile markers Posted Sep 8, 2008 19:52 UTC (Mon) by roelofs (subscriber, #2599) [Link] It's just like the recent trend of renumbering Interstate exits to match the mile markers: changing the convention provides no *new* information (there were mile markers along the side of the road already, thank-you-very-much)Not in California (much to my amazement). :-/ Greg
|
|
||||||||||||