## Auto-converted by kwiki2moinmoin v2005-10-07 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 Pros: * 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. Cons: * 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.