Eduard Bloch wrote: > Just my 0.02EUR: Let's call it after the year when it is going to > be released. For example, if Sarge will be ready in this year (what I > doubt), it would be called 3.1, and Sarge+1, released 2004, will be > Debian 4.0, Sarge+2 somewhere end of 2002 would be called 4.1, etc. I think you mean "Sarge+2 somewhere end of 2004", right? And why would Sarge+1 be called 3.1? 3.0 came out last year, so if I understand your proposal, Sarge+1 will be called 4.0 because it will be the first release this year (or next). > Why this? A long development period is an indicator for major changes, > eg. gcc-3.2 transition. However, long development periods don't necessarily correspond to changes of years as nicely as you might like. Let's say we put out Sarge in January 2004, then Sarge+1 in November 2004, then Sarge+2 in March 2005 (I know this isn't likely given Debian's history, but consider it anyway). By your logic and this schedule, Sarge will be 4.0, Sarge+1 will be 4.1, and Sarge+2 will be 5.0. However, note that the time delta between Sarge and Sarge+1 is 10 months, while the delta between Sarge+1 and Sarge+2 is only 4 months. So why does Sarge+2 get a new major version while Sarge+1 doesn't? Another point is that by your proposal, every new Debian release will get a new major version, since Debian, historically, tends to put out no more than one new release per year, if even that. So in practice, your proposal is equivalent to "just use a single integer version number". > Just changing the major number to be proud of > some new version does not work, since the freeze time is so long that > that we often release with outdated software. Numbers and names are for > marketing people. This is largely true. It doesn't really matter what we call our releases as long as there's some clear indication that it's a new release. Any number greater than that of the last release will do, when you get down to it. So I prefer the idea of simplifying the number to a plain integer, as suggested at the start of this thread. It's simple, it's understandable, and it will put an end to all the silly arguments we have EVERY RELEASE about whether the new release should be N.[1-9] or (N+1).0. Craig
Attachment:
pgpXyI8kPubSQ.pgp
Description: PGP signature