RFC: binary compatibility between short cycles

[Evan]

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:

Divide Ubuntu (packages & development) into two sections:
>
>    - The core (X, the Kernel, etc.)
>       - Minor versions
>       - are released with each normal release.
>          - are developed in the current six-month cycle.
>          - include only features that can be fully and properly
>          implemented in a single six-month time frame.
>       - Major versions
>       - are released with each LTS.
>          - are developed in a two-year cycle.
>          - include all of the larger features that take longer than six
>          months to implement.
>       - 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.
>    - The apps (Firefox, OpenOffice.org, etc.)
>       - Rolling release cycle
>       - Freeze for every LTS on last stable version
>
> It's fairly complicated, but it seems to satisfy most of the requirements:
>
>    - large corporate environments get a stable, constant release every two
>    years.
>    - home users get up-to-date applications on a stable base.
>    - those who need a very stable base but up-to-date apps can install the
>    LTS but then switch to the rolling apps repository.
>    - developers aren't rushing to cram a complex feature into six months.
>
>  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]
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-December/002803.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20090701/6d7ad0f9/attachment.html>