Summary: Have major releases and minor releases
Although Debian is the "Universal OS", different users have different needs; there is no single release model that will them all happy. Desktop users are the users that brag [complain?] the most about our release cycle. They want up-to-date software available at all times. Server users are more conservative (although even they are probably fed up with Woody) and can stand a longish cycle (probably ~18 months instead of the 30 we now have).
So, this proposal is a compromise between two of the other ones suggested: ReleaseWhenReady (as in "we want a rock-solid release as our users trust our QA") and DropStableJustUseTesting (as in "we want something up-to-date at all times").
My proposal is basically: Desktop systems do not usually require the same QA level as server systems. We can set up a release schedule for Debian_minor, make it quite fast (probably even something close to Mandrake's. Parallel to it, we will still have a stable release as today's, Debian_major, following the same stability policies we now have.
We would provide security support for both branches, but in a different way: Security support for Debian_major would be just as it is today: Backport fixes, keep stable versions. Security support for Debian_minor might involve upgrading versions (but will not always, only if the fix is hard to backport - this compromise would be made to make the Security team's lifes easier).
Now, a user might get lost among parallel releases. I think it would be foolish to start a new numeration scheme such as RedHat's (... 5, 6, 7, 8, 9, 2, 3?). As our Debian_minor releases would represent intermediate steps between Debian_major releases, were we to adopt this model as soon as Sarge hits the street, we would have a simultaneous Debian_major 3.1 and Debian_minor 3.1+minor0. Debian_major could release point releases as it does today (3.1r1, 3.1r2, ...), and Debian_minor would have a life cycle of its own inside the 3.1 series (3.1+minor1, 3.1+minor2). The difference would be, of course, that the minor releases would have new versions, new software, etc., while the point releases would not. Once Etch (3.2?) is out, we would have again 3.2+minor0 equaling 3.2.
Wrapping up: This scheme is quite similar to what we have today, only giving more protagonism (and some intermediate freezes) to Testing. We would need to create a fourth branch of the distribution, yes, but it should not skew far away from testing, and should not represent to high a load for our archive
- Users can always have an up-to-date distribution
- We still maintain high QA levels
- We have a stronger incentive to keep testing in a releasable state
There would be a much lesser upload flurry whenever a freeze is announced - first, because we would all know when freezes are coming up. Second, because if our package doesn't enter this Debian_minor release, it would enter the next one. And if it doesn't appear on a Debian_major release, it will still appear on subsequent Debian_minor ones.
- We have a weaker incentive to do the full chore of preparing a Debian_major (aka stable) release - What happens if we never get to it?
- Harder to implement large-scale changes in a limited timeframe
- Needs more commitment from all of us - We just cannot go MIA for two months anymore, as we would have the minor release going on.
Proposed by: GunnarWolf
Even though I fail to see the real difference with the TwoReleases proposal, I feel that this is really a good idea, and that it incorporates a lot of other good ideas that are present on this wiki pages.
About the cons, I think that both for the Debian_major and the Debian_minor we should have a FixedReleaseDate, this encourages work and helps to get the commitment needed. Ideal timeframe would be 6 months for the minor release and 18 for the major. The principal con I find, however, is the additional infrastructure. The infrastructure problem is right now Sarge's main blocker, and I fail to see how this proposal addresses this :(.
And about the numbers, I'd say something like next major 4.0, next minors: 4.2, 4.4, 4.6 (we like the old kernel numbering, don't we?) and then, when there's a stable update, we can have 4.0.1, and if there is such thing as a minor update we could have 4.2.1. This transmits the fact that these minor releases are based on a certain major, and the main number does not change until there's a new major. I think it's better to reuse this widely understood method instead of coming up with a new one (Yeah, I know you want to be unique, but if we are devoted to our users we need to make things user-friendly). -- Margarita Manterola
See ReleaseProposals for alternatives.