I started a discussion somewhat along these lines quite a while ago. My original plan started quite different from yours, although it morphed into something actually quite similar based on various feedback. The archive link is at [1] for reference, but I'll copy the body of my final revision here for easier reference: <blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Divide Ubuntu (packages & development) into two sections: <ul><li>The core (X, the Kernel, etc.) </li><ul><li>Minor versions </li><ul><li>are released with each normal release.</li><li>are developed in the current six-month cycle.</li><li>include only features that can be fully and properly implemented in a single six-month time frame. </li></ul><li>Major versions </li><ul><li>are released with each LTS.</li><li>are developed in a two-year cycle.</li><li>include all of the larger features that take longer than six months to implement.</li> </ul><li>The focus for core will always be on stability. If something can't be implemented and tested properly for the next minor release, it is dropped to the next major release instead. </li></ul><li>The apps (Firefox, OpenOffice.org, etc.)</li><ul><li>Rolling release cycle</li><li>Freeze for every LTS on last stable version</li></ul></ul> It's fairly complicated, but it seems to satisfy most of the requirements: <ul><li>large corporate environments get a stable, constant release every two years.</li><li>home users get up-to-date applications on a stable base.</li><li>those who need a very stable base but up-to-date apps can install the LTS but then switch to the rolling apps repository. </li><li>developers aren't rushing to cram a complex feature into six months.</li></ul> </blockquote> The original focus of my plan was actually to introduce a rolling repository for user-facing applications (I don't remember which app it was that prompted the discussion), but it sort of grew from there. The general consensus at the time was that people who wanted up-to-date apps were best served simply by enabling the backports repository, and that if things weren't moving through the backports queue fast enough then volunteers were always welcome. I also have to note that while Gutsy was a mess (for me at least) everything since has been quite stable, so my complaints about instability in the "Core" have also disappeared. If I understand correctly though, your plan is to ensure binary compatibility between minor releases, so that moving from version x to version y wouldn't require a rebuild of package z if there is no new version of package z. There are some interesting benefits to this, especially to third-party developers, but as you mention there would be a larger load on maintainers of "Infrastructure" packages. Also, I would like to have a more precise definition of "Infrastructure" packages. Anything with a public API seems rather broad, but I believe necessary to maintain complete compatibility between releases. It is a very interesting idea, and I look forward to seeing how it develops. Evan [1] <a href="https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-December/002803.html" target="_blank">https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-December/002803.html</a>