RFC: binary compatibility between short cycles

Felipe Figueiredo philsf79 at gmail.com
Wed Jul 1 12:57:01 UTC 2009


Hello,

a slightly longer version of this proposal is posted in [1].

I have seen that changes are being planned [2] for the release cycles,
and I'm excited about what's to come. But I still feel Ubuntu can do
better, and easier, provided at least some of my premises are correct.

The main premise is that binary compatibility between 6-month releases
would do more good than harm, and would allow for an idea I've have a
couple of years ago to be implemented: break the repos in two
'sections' (this is an already reserved name in the context, but I
couldn't find a more proper one), one for 'Infrastructure' packages, and
the other for 'Interface' packages.

Infrastructure could be kept at stable versions for longer cycles, and
Interface would match the usual 6 month release cycle. Infrastructure
would be loosely defined as 'whatever needs to be kept to provide binary
compatibility' (glibc and friends).

Some major benefits I can see in this, is that if you share the
Infrastructure packages between cycles, it reduces maintenance
resources, mirror storage usage, smoothen dist-upgrades and offer third
party developers a more stable environment, while still giving users the
latest Gnome (and KDE), Mozilla, etc.

Some drawbacks would be that some packages would require further
maintenance effort, if the version used were deprecated upstream. This
could, obviously, be handled by the already implemented SRU process, but
it would also affect a larger install base (some might regard this as a
plus). Another would be the possibility that users screw up by mixing
versions from several releases, the same way Debian users do, when they
mix stable, testing and sid (again, some might consider this a feature).

I don't pretend to understand the full complexity of a distribution
maintenance, but I think this proposal could benefit both users,
maintainers and developers.

Maybe this could be throughly planned for a year, and assuming the next
LTS is Karmic+1, be implemented in Karmic+2? The effect would be to blur
the difference between LTS and non-LTS releases by having a common
package base in the intersection between the two kinds of releases.

Comments?

links
1.
http://sciwannabe.blogspot.com/2009/06/rfc-new-paradigm-for-ubuntu-release.html

2. http://www.markshuttleworth.com/archives/288







More information about the Ubuntu-devel-discuss mailing list