Six-month cycles are great. Now let’s talk about meta-cycles: broader release cycles for major work. I’m very interested in a cross-community conversation about this, so will sketch out some ideas and then encourage people from as many different free software communities as possible to comment here. I’ll summarise those comments in a follow-up post, which will no doubt be a lot wiser and more insightful than this one :-)

Background: building on the best practice of cadence

The practice of regular releases, and now time-based releases, is becoming widespread within the free software community. From the kernel, to GNOME and KDE, to X, and distributions like Ubuntu, Fedora, the idea of a regular, predictable cycle is now better understood and widely embraced. Many smarter folks than me have articulated the benefits of such a cadence: energising the whole community, REALLY releasing early and often, shaking out good and bad code, rapid course correction.

There has been some experimentation with different cycles. I’m involved in projects that have 1 month, 3 month and 6 month cycles, for different reasons. They all work well.

..but addressing the needs of the longer term

But there are also weaknesses to the six-month cycle:

  • It’s hard to communicate to your users that you have made some definitive, significant change,
  • It’s hard to know what to support for how long, you obviously can’t support every release indefinitely.

I think there is growing insight into this, on both sides of the original “cadence” debate.

A tale of two philosophies, perhaps with a unifying theory

A few years back, at AKademy in Glasgow, I was in the middle of a great discussion about six month cycles. I was a passionate advocate of the six month cycle, and interested in the arguments against it. The strongest one was the challenge of making “big bold moves”.

“You just can’t do some things in six months” was the common refrain. “You need to be able to take a longer view, and you need a plan for the big change.” There was a lot of criticism of GNOME for having “stagnated” due to the inability to make tough choices inside a six month cycle (and with perpetual backward compatibility guarantees). Such discussions often become ideological, with folks on one side saying “you can evolve anything incrementally” and others saying “you need to make a clean break”.

At the time of course, KDE was gearing up for KDE 4.0, a significant and bold move indeed. And GNOME was quite happily making its regular releases. When the KDE release arrived, it was beautiful, but it had real issues. Somewhat predictably, the regular-release crowd said “see, we told you, BIG releases don’t work”. But since then KDE has knuckled down with regular, well managed, incremental improvements, and KDE is looking fantastic. Suddenly, the big bold move comes into focus, and the benefits become clear. Well done KDE :-)

On the other side of the fence, GNOME is now more aware of the limitations of indefinite regular releases. I’m very excited by the zest and spirit with which the “user experience MATTERS” campaign is being taken up in Gnome, there’s a real desire to deliver breakthrough changes. This kicked off at the excellent Gnome usability summit last year, which I enjoyed and which quite a few of the Canonical usability and design folks participated in, and the fruits of that are shaping up in things like the new Activities shell.

But it’s become clear that a change like this represents a definitive break with the past, and might take more than a single six month release to achieve. And most important of all, that this is an opportunity to make other, significant, distinctive changes. A break with the past. A big bold move. And so there’s been a series of conversations about how to “do a 3.0”, in effect, how to break with the tradition of incremental change, in order to make this vision possible.

It strikes me that both projects are converging on a common set of ideas:

  • Rapid, predictable releases are super for keeping energy high and code evolving cleanly and efficiently, they keep people out of a deathmarch scenario, they tighten things up and they allow for a shakeout of good and bad ideas in a coordinated, managed fashion.
  • Big releases are energising too. They are motivational, they make people feel like it’s possible to change anything, they release a lot of creative energy and generate a lot of healthy discussion. But they can be a bit messy, things can break on the way, and that’s a healthy thing.

Anecdotally, there are other interesting stories that feed into this.

Recently, the Python community decided that Python 3.0 will be a shorter cycle than the usual Python release. The 3.0 release is serving to shake out the ideas and code for 3.x, but it won’t be heavily adopted itself so it doesn’t really make sense to put a lot of effort into maintaining it – get it out there, have a short cycle, and then invest in quality for the next cycle because 3.x will be much more heavily used than 3.0. This reminds me a lot of KDE 4.0.

So, I’m interesting in gathering opinions, challenges, ideas, commitments, hypotheses etc about the idea of meta-cycles and how we could organise ourselves to make the most of this. I suspect that we can define a best practice, which includes regular releases for continuous improvement on a predictable schedule, and ALSO defines a good practice for how MAJOR releases fit into that cadence, in a well structured and manageable fashion. I think we can draw on the experiences in both GNOME and KDE, and other projects, to shape that thinking.

This is important for distributions, too

The major distributions tend to have big releases, as well as more frequent releases. RHEL has Fedora, Ubuntu makes LTS releases, Debian takes cadence to its logical continuous integration extreme with Sid and Testing :-).

When we did Ubuntu 6.06 LTS we said we’d do another LTS in “2 to 3 years”. When we did 8.04 LTS we said that the benefits of predictability for LTS’s are such that it would be good to say in advance when the next LTS would be. I said I would like that to be 10.04 LTS, a major cycle of 2 years, unless the opportunity came up to coordinate major releases with one or two other major distributions – Debian, Suse or Red Hat.

I’ve spoken with folks at Novell, and it doesn’t look like there’s an opportunity to coordinate for the moment. In conversations with Steve McIntyre, the current Debian Project Leader, we’ve identified an interesting opportunity to collaborate. Debian is aiming for an 18 month cycle, which would put their next release around October 2010, which would be the same time as the Ubuntu 10.10 release. Potentially, then, we could defer the Ubuntu LTS till 10.10, coordinating and collaborating with the Debian project for a release with very similar choices of core infrastructure. That would make sharing patches a lot easier, a benefit both ways. Since there will be a lot of folks from Ubuntu at Debconf, and hopefully a number of Debian developers at UDS in Barcelona in May, we will have good opportunities to examine this opportunity in detail. If there is goodwill, excitement and broad commitment to such an idea from Debian, I would be willing to promote the idea of deferring the LTS from 10.04 to 10.10 LTS.

Questions and options

So, what would the “best practices” of a meta-cycle be? What sorts of things should be considered in planning for these meta-cycles? What problems do they cause, and how are those best addressed? How do short term (3 month, 6 month) cycles fit into a broader meta-cycle? Asking these questions across multiple communities will help test the ideas and generate better ones.

What’s a good name for such a meta-cycle? Meta-cycle seems…. very meta.

Is it true that the “first release of the major cycle” (KDE 4.0, Python 3.0) is best done as a short cycle that does not get long term attention? Are there counter-examples, or better examples, of this?

Which release in the major cycle is best for long term support? Is it the last of the releases before major new changes begin (Python 2.6? GNOME 2.28?) or is it the result of a couple of quick iterations on the X.0 release (KDE 4.2? GNOME 3.2?) Does it matter? I do believe that it’s worthwhile for upstreams to support an occasional release for a longer time than usual, because that’s what large organisations want.

Is a whole-year cycle beneficial? For example, is 2.5 years a good idea? Personally, I think not. I think conferences and holidays tend to happen at the same time of the year every year and it’s much, much easier to think in terms of whole number of year cycles. But in informal conversations about this, some people have said 18 months, others have said 30 months (2.5 years) might suit them. I think they’re craaaazy, what do you think?

If it’s 2 years or 3 years, which is better for you? Hardware guys tend to say “2 years!” to get the benefit of new hardware, sooner. Software guys say “3 years!” so that they have less change to deal with. Personally, I am in the 2 years camp, but I think it’s more important to be aligned with the pulse of the community, and if GNOME / KDE / Kernel wanted 3 years, I’d be happy to go with it.

How do the meta-cycles of different projects come together? Does it make sense to have low-level, hardware-related things on a different cycle to high-level, user visible things? Or does it make more sense to have a rhythm of life that’s shared from the top to the bottom of the stack?

Would it make more sense to stagger long term releases based on how they depend on one another, like GCC then X then OpenOffice? Or would it make more sense to have them all follow the same meta-cycle, so that we get big breakage across the stack at times, and big stability across the stack at others?

Are any projects out there already doing this?

Is there any established theory or practice for this?

A cross-community conversation

If you’ve read this far, thank you! Please do comment, and if you are interested then please do take up these questions in the communities that you care about, and bring the results of those discussions back here as comments. I’m pretty sure that we can take the art of software to a whole new level if we take advantage of the fact that we are NOT proprietary, and this is one of the key ways we can do it.

288 Responses to “Meta-cycles: 2-3 year major cycles for free software?”

  1. Meta-cycles: 2-3 year major cycles for free software? | The Linux Blog Says:

    […] Read the rest here:  Meta-cycles: 2-3 year major cycles for free software? […]

  2. David Goodger Says:

    For the name, “long cycle” ties in well to “long-term support”. Regular releases could be on the “short cycle” or “regular cycle”.

    There’s the “great circle”, a largest-path circle around a sphere (across the diameter); the term “great cycle” could be adopted. “Great cycle” already has a time-related meaning: it normally means the 25,920 year Precessional Cycle, the time it takes for the Earth’s north pole to wobble once and point back to its starting point.

    Also: “grand cycle”.

  3. Stephen Says:

    Why not take some flexibility in the choice and say, it will be one of three release… such as every 2 years with the option of + 6months or +12months; for the purpose of patch sharing with Debian or the like :)

    I know you love your time based releases, but there is a benefit in being flexible enough to be opportunistic :)

  4. Jared Spurbeck Says:

    How about just “new versions?”

    It seems a little counter-intuitive, but when you think about it, our practice of calling minor bugfixes and patches “new versions” is counter-intuitive itself. I can’t tell my non-Ubuntu friends that there’s a “new version” of Ubuntu because hardly anything’s changed. They’re used to things like Leopard’s “300 new features,” and how Windows Vista was markedly different from Windows XP (for better or for worse).

    Our “new versions” are really less like “new versions” and more like the patches that they release for an MMORPG, like World of Warcraft. Even if they add new features, they’re rarely if ever game-changing. Maybe we should come up with a different name for them, and save the term “new versions” for things like KDE 4.0, things that change everything in the way that Wrath of the Lich King does …

    … if that makes any sense.

  5. Mackenzie Says:

    To me, a single-year cycle seems like the way to ensure a good amount of testing without getting too outdated. Not as stale as Debian stable, but not as bleeding edge as Fedora.

  6. Joseph Smidt Says:


    I always enjoy your blog posts. This is my unifying philosophy:

    1. 6 Month Cycles: These are best for getting the best of free software out quickly for immediate testing and or contributor feedback. I honestly don’t think the 6-month release can ever become the bedrock of mainstream use. Here you need to have the “release early, release often” mentality.

    2. LTS Cycle: This is best for providing a “final” product which the mainstream world can build upon and rapidly support and promote. This release is best for users who do not care about the latest new features in Linux, just want something that works well. Here you need the “release whe it’s ready” mentality. (Though I would confine yourself to a 2-3 year window so you don’t pull a Perl 6.)

    Lastly, I think releasing alongside Debian is a very smart move. You really would be shooting your developers in the foot by taking away a great opportunity to collaborate with Debian and share code.

    Also, I’m interested in your new UI ideas, but frankly they seem to be trickling in very slowly. (Only notifications). This isn’t trying to be a criticism, it just seems this UI work takes time to do it properly and having it all rock hard stable in a year, where the majority hasn’t even started to be tested I think is a stretch.

    Lastly, Gnome 3.0 may not be the best release to base an LTS on. There may be some small “KDE 4.0” effects that would be nice to have an extra 6 months to iron out. Your end users would like to have a polished Gnome 3.X version.

    So, again, I like your post and applaud your idea to move the LTS back to 10.10. That is when I believe it will “be ready”.

  7. Davide Del Vento Says:

    Mark, your posts are always very interesting.
    Software development desperately needs both frequent “maintenance” releases as well as “big bold moves”.

    I agree with you that a whole-year cycle is highly desiderable, and I slightly prefer a 2-year cycle versus the 3-year one: life don’t wait, things change quickly. But a 3-year one is ok too, especially if it means “bigger bolder moves”. 30- or 18-months releases? Not good! Why don’t 10*pi months, or 10*e, or 50*sqrt(1/pi) then?

    I strongly believe that the LTS must be something like the result of a couple of quick iterations on the “big bold move”, like GNOME 3.2! It does matter quite a lot. Ubuntu 8.04LTS (which I am using right now on 5 different client machines, laptops and desktops) did a great job selecting firefox 3. Imagine being in October 2010 still with firefox 2! On the server is even worst: I use some machines (which I don’t administer, they are RHEL), I’m stuck with libraries from the Jurassic…. and I can’t install things I need because of that!

    Obviously, then, LTS will have the same 2- or 3-year cycle of the “big bold move”, but shifted (say) ~6 months. And another very important things (actually one of the the “killer features” why I chose Ubuntu): the LTS’s must “overlap” at least 6-months, better if it’s a whole year, to give everybody plenty of time for a painless upgrade.

    And kudos to you for trying to synchronize Ubuntu with other projects, I think that would be great too.

    Sorry I don’t have suggestions for names, I’m bad at that.

  8. Sigh Says:

    Maybe for developers time-based releases seem like a good idea, but as a user, it feels like a big mistake; as though the product is being shoved out the door haphazardly to meet an arbitrary deadline without sufficient testing or bug-fixing.

    With every release, something new is broken. Gnome session saving, PulseAudio, Nvidia cards failing that used to work fine, etc. What’s worse is that when I go to file a bug, it’s already been filed, even before the release. You know this is going to cause major problems and then you push it out to my computer anyway? How is this a good idea?

    I know I’m not the only one with this experience. It’s even lampooned on the Linux Hater’s blog:

    When I “upgrade” something on my computer, I expect it to fix problems or introduce new features, not to introduce new problems or break existing features.

  9. Comment For Mark’s “Meta-cycles” post « California Quantum Says:

    […] “Meta-cycles” post I left this as a comment on Mark Shuttleworth’s recent blog post.  I am only posting it here because I was told it was removed as spam.  Perhaps too long?  […]

  10. Glubbdrubb Says:

    As for the name, how about triple cycle (18 months) or quadruple cycle (yes, this does not sound as good). But I do like grand cycle.

    Although there are pros and cons about this issue, I am sure we will manage just fine with which ever system we settle on.

  11. Joseph Smidt Says:


    I have one more opinion I would like to express. :)

    I believe Fedora does the 6-month cycle better and Ubuntu does the LTS release better. (Though Fedora doesn’t have and LTS release)

    Though I may be repeating myself let me re-emphasize:

    1. Your contributor community, in my honest opinion, would be much more energized if the 6-month Ubuntu cycles were as fast paced as Fedora’s. Developers and testers get more excited when your feature list looks like Fedora 11, as opposed to Ubuntu 9.04.

    2. Your “I don’t care about the latest feature I want something that just works” users would be happier with an LTS release. They want something stable and universally supported for all their computing needs. This can’t happen that well in 6-months. Your LTS released should be geared toward them.

    However, to keep the LTS people from running a 2 year out Firefox, etc… I do think you should update the most popular packages of your LTS release during the 6 month LTS.X updates, after these packages become stable and well tested.

  12. Tom Says:

    I am not sure if this idea would work for KDE. 3 years would mean that KDE5 should be ready by 2011. That is way too soon IMNSHO. Not all apps have been ported and they haven’t even begun to use their semantic stuff in all apps and a lot of other technologies in KDE4 can still be improved and integrated even more. So for really advanced big projects like KDE that long term cycle should probably closer to 5 years. I know it sounds like ages in ICT, but I guess I am right (of course XD ).

    But in general I think the idea of cadence is a very important one and I am glad that you think so too. We have most pieces for that puzzle now. Distributed bug tracking is probably the only one missing (would be best if integrated into a DVCS, maybe bzr 😉 )

  13. Felix Pleșoianu Says:

    “Potentially, then, we could defer the Ubuntu LTS till 10.10, coordinating and collaborating with the Debian project”

    Except they will be late, and that will mess up your release cycle completely.

    Note: I don’t mean to criticize Debian. It’s just that they *will* be late.

  14. edajai Says:

    i agree with Jared.
    I personally think that we should give a lot more importance to the LTS releases. These releases are more easy for companies like DELL etc to support too. What I suggest is that we should introduce code names like hardy for one full cycle instead of one name for each 6-month release. This gives enough time for the name to get popularity. So we should have a hardy LTS cycle, where further releases like 8.10 9.04 etc happens, and for the next LTS cycle a new name should be suggested which will again have more releases.

  15. Setsuna Says:

    I personally would opt for the 2-years cycle. Maybe I’m overlooking something but do longer release cycles not mean that developers are bound to support older releases for a longer time and thus limiting the ressources needed to make the next big release?

  16. ethana2 Says:

    “Our “new versions” are really less like “new versions” and more like the patches that they release for an MMORPG, like World of Warcraft. Even if they add new features, they’re rarely if ever game-changing.”

    I actually find just about every release game changing. I upgrade on the last alpha or beta of a new version, then I get so hooked I can’t go back to the stable release. This time around, nvidia drivers in Jaunty enabled me to switch to gnome-do’s docky to complement my gnome-globalmenu. In conjunction with the Dust theme, I’d say I have a sleeker desktop than OS X, while retaining most of its usability and avoiding its confusing window management.

    Keep in mind that those ‘300 features’ only come once every couple years. With Ubuntu’s more rapid release cycle, you have more time to get used to new features, so individual releases stand out less. –it’s not about individual releases though. It’s about the OS; the technology, the community, the brand. Most Ubuntu users use the latest stable release. With OS X and Windows, this will not always be the case as upgrades to those OS families are both nonfree and infrequent. Mac OS X and Windows are not moving targets like Ubuntu is, they are a series of stationary ones, and it’s little by little that we’ll hit them one by one.

    It seems to me that the natural progression of software is to add features, add features, add features, refactor the code base, rinse repeat. I should think regular releases would be better in the feature adding stages with a double-length release window for rewrites. For instance, if Sun GPLed OpenSolaris and it merged with Linux, I’d say Torvalds make a six month release cycle for that.

  17. Jacob Says:

    Consolidation is a well known term that remains to be valid for anything really. A marriage need consolidation to establish a solid base to stand on. A server needs to be consolidated before it gets utilised and deemed safe for usage.

    KDE 4 has been through a tough development period. In many ways KDE 4 now goes through consolidation where bugs are ironed out and the various segments are carefully optimised and evolved. New functionality gets built on the consolidated base and suddenly everything evolves into place. It becomes GOOD!

    Now. Consolidation IS NOT about stagnation or recession. It’s about ensuring that targets were met, improving processes and get the basics right. For future progress and invention.

    Gnome appears to have confused it’s consolidation with evolution. Consolidation cannot replace innovation and progress. If consolidation becomes the primary object there will be no innovation and no progress.

    What I have missed in the established 6-month cycle of distributions is that the consolidation process missed out in the battle with progress. Therefore there still are areas with glitches. The simple examples are distro-specific bugs and hardware with Linux-support that does not work in all distros.

    My definition of a Distro is that it has it’s own repo and maintain their own packages. If not – it’s a spin or a derivate. No fence intended – the spinoffs provide valuable alternatives.

    So, what about cycles? Duration? Naming?
    I feel that 3 years will be hurting evolution and development. Consolidation will become the primary object. Balance is a key issue, and 2 years will provide a better balance and provide less risk of stagnation.

    I believe that establishing a term: “Consolidated Linux” will be understandable for anyone and it can be established as a quality branding that can be adopted by the distros AND reckognised by enterprises.

    Therefore my proposal is:

    Ubuntu 10.10
    Consolidated Linux

  18. Flimm Says:

    A rapid release cycle does mean fewer new features to get excited about in each release. The answer to this is good marketing: the next time Ubuntu release’s a LTS version, we should list all the new features compared to the previous LTS, rather than just the previous “short-cycle” release.

  19. Phillip Says:

    I am looking forward to other distro’s participation on this front. If Debian and Ubuntu got on similar release cycles it would be like the planets aligning for most developers!

    With jaunty there where “few” new features most said. And while that is true I have had the pleasure of running it since alpha 4 and LOVED it. EXT4, faster OO.o 3 , and the new notifications where what got me to upgrade from 8.10. While others won’t switch until support runs out.

    Psychologist call it the JND or Just Noticeable Difference, some people’s JND tolerance is low, some high. It’s like when you hear a loud radio and you say turn it down…they barely move the volume, but swear it was alot.

    One think I thought about with doing the “radical changes” is that by the time the Radical changes get stable enough, the slow and steady releases are already there…as long as they are willing to change. Case and point with the new OSD-notify system. That is RADICALLY different, not only in looks (which rock) but in function, they no longer DEMAND your attention and don’t actually ask for an action…the program ask, not the notification balloon! This is a good example off the steady eddies doing something great, aslong as they are willing to change. GNOME just never had the NEED to change, until after KDE did their thing (which some people i hear STILL dislike). Again, all comes back to the JND :)

    Either way, I’m still a HUGE ubuntu supporter.

  20. FreeAtMind Says:

    3 years for Ubuntu LTS, enterprise need that, maybe until more years…
    2 years for projects like GNOME and KDE, and maybe in release versions like 4.0 and 2 years later version 4.5.
    I think incremental releases are always better, not all at same time, because stability are best archived if you change one thing at time.
    For desktop users keep the 6 months cycle, and maybe if some enterprise need more often updates can use regular releases.

    Cya… sorry for my english.

  21. mpt Says:

    Development planning is not the only issue to consider in deciding on release cycles. Other issues include support and documentation, version branding, and the upgrade cycle.

    For support and documentation, each major new version means revising books about Ubuntu, and also instructions provided by legions of university IT departments, ISVs, company intranets, tech tips Web sites, and so on. To a large extent these books and Web sites can say “If you’re using a later version, these instructions probably will still work”, but “probably” isn’t particularly reassuring.

    For version branding, as Jared mentioned above, it’s harder to get enthusiastic about a “new version” of Ubuntu if there are few visible changes. A related issue is that Ubuntu’s year-dot-month version numbering system is difficult to understand for many people, even tech journalists. For example, according to Google, 1.3 percent of the pages mentioning Ubuntu 8.04 refer to it as “Ubuntu 8.4”. And I/O Books has gone as far as publishing and selling a user guide for the non-existent “Ubuntu8”.

    On the upgrade cycle, I have no special knowledge of this but I would expect even those organizations that stick to LTS releases would find a two-year interval rather quick. For example, there are numerous accounts of companies sticking to Windows XP until Windows 7 arrives, representing a gap of up to eight years. Microsoft and Apple can afford to support more widely-spaced upgrades because of their larger development teams, but perhaps it would be easier for us to support similar spacing if we had fewer minor releases between the major ones.

  22. puntium Says:

    I never really understood why you can’t do both short term and long term stuff. A bunch of distros shipped KDE4 and KDE3 at the same time and let users pick. If you want the bleeding edge, you can have it, and if you want to wait until things “come into focus”, you can do that too. The only mistake that was made in the KDE stuff really was that upstream made it hard for distros to present the choice, and some distros jumped the gun in advertising KDE4 as a comprehensive alternative.

    If Gnome/Ubuntu is to learn anything from this, they should figure out a way to allow deployment of Gnome 3 alongside Gnome 2. And have a sane story of the migration of apps. Fine, you can’t make two “shells” run at the same time, but don’t make it as much of an either/or story like KDE did. If you can do this correctly, then it doesn’t matter who’s on what cycle. Users will pick whatever works for them. Don’t let architectural purity be the enemy of providing users with a useful combination of new and old code.

  23. Paul Firth Says:

    I think one thing which comes up in discussion of releases is testing and whether the new, potentially problematic, features of the longer cycle will get adequate testing.

    One method to address this would be to release these high impact features as non-default in the 6 month releases so that those who were inclined would be able to switch them on and test. Then, for the LTS or equivalent, they could be switched on as default.

    Hope that makes sense.

  24. Russ Brown Says:

    For the name, how about “release arc”?

  25. Dave Johansen Says:

    I believe that the concept of releasing a x.0 that’s not at the same quality of the previous release is a big mistake. Obviously, nothing will be perfect right out of the gate, but intentionally releasing a new version that doesn’t meet the existing expectations of quality/stability creates a mentality that new versions aren’t good enough/usable and that people need to wait for the first “service pack” before anything is even worth considering.

    “Big bold moves” that break more than they fix just slow adoption and can even push people away. For example, Microsoft is currently trying to fight off HUGE negative hype about Vista, but the Vista of today and the Vista of release are dramatically different products and how many of the issues that they face today would have been averted if the original release had been at the same quality as Service Pack 1?

    Basically, “big bold moves” are important and essential, but they should never come at the cost of degraded quality/stability, even if it is just during the “initial release”.

  26. gsmx Says:

    I thought of this a while ago and my conclusion was: why not skip one 6 month-cycle before every LTS. If 10.04 would be LTS, we are too late, as announcements for 9.10 are already made. But if we decide to bring 10.10 up as an LTS, we could NOW decide on skipping a 10.04 release. Especially for the now-in-mailinglist discussion about new a packet management system, which is a very delicate and complicated task that requires a lot of time.

    IMHO this has only benefits:
    – It’s still ‘release often’ compared to proprietary software
    – Big changes can be stabilized and perfected due to a larger timeframe (eg the new packet management)
    – Visible big changes can be very well marketed
    – The overall visibility of new features will increase

  27. Evan Says:

    There was a discussion about this on Ubuntu-devel-discuss a while back, starting at

    The original suggestion went through many iterations, and although nothing ever came of it, a lot of good issues were brought up. Here’s my take from all of this:

    Any plan needs to try to fulfill all of the following requirements:

    1. Large corporate environments get a stable, constant release two years or so.
    2. Home users get up-to-date applications on a stable base.
    3. Developers aren’t rushing to cram a complex feature into a short release cycle.
    4. Any release that is supported for a significant length of time (ie LTS releases) need to be able to support modern hardware some time after the release.

    1 is already done by the current system.

    2 is impossible. A rolling release cycle would be the only way to get regularly up-to-date applications, but would cause instability in the core system (kernel, X, etc.). Not sure if the current compromise (6-month mini-cycles) is the best way to go.

    3 can be easily fixed: have LTS development start a cycle or two earlier than otherwise (so maybe 10.04 development would start after Jaunty, not after Karmic), and run it in the background to the current cycle. This way there’s already significant momentum for it once it becomes the primary development release, and there is a code base for people to work with when writing more revolutionary apps over a much longer time period.

    4 is difficult, and something that needs to be addressed in whatever we decide on. Perhaps make more of a service pack out of the LTS CD-rerolling (ie 8.04.1, 8.04.2, etc.), and update certain core components then? It would still be tricky to keep it stable, but with proper testing of service packs it could be done.

  28. Brian Fleeger Says:

    How about “sub-cycle” and “super-cycle”? referencing their hierarchical relationship

  29. Marcus Moeller Says:

    Good Evening.

    I wonder if you can bring all these projects together to work within specified release periods. Most of them (GNOME,KDE,OOo..) have different aims and even different userbases.

    I agree that a common release strategy could make sense, but who is going to handle an overall release cycle management?

    As I read between the lines, you are looking for a better way to handle LTS releases/sec Updates for Ubuntu and maybe other distributions. In my pov, this is not a topic of the open source projects, but of the Linux distributor.

    Take a look at Red Hat. They provides one of the most effective update infrastructure and release cycle management for their enterprise products. But how does it work? They just take a version of the Kernel, X and the Desktop Environment (not a beta one, and not a fresh major version) and freeze it.

    Then they put manpower in backporting apps, drivers and patches for a long time. That’s all. No magic, but a lot of work.

    So the only way one could profit from, is to define LTS version of software components that all enterprise distributions should/could use to share patches.

    Best Regards

  30. Tim Says:

    Such a good article. The quality of Ubuntu has suffered with the the strict 6 month approach, although it clearly has very strong benefits which outweigh the costs for many users . If this article means that Ubuntu will slow down and make LTS releases based on a different weighting of “new and shiny” vs “mature”, everyone’s a winner. Just imagine if there was one Ubuntu release every two years that had Debian’s quality … wouldn’t that be something? It would be awesome. The idea of working with Debian on this is great, because when Debian makes a release, they create on OS which in my experience is extremely reliable. The culture of preferring “it works” over “its new and shiny” may be a bit of a challenge for Ubuntu (Lenny shipped with Nautilus 2.20 and pulse audio off by default), but if it’s one mature, grown-up release every two to three years, and back to new and shiny six months later, why not? Really good luck with this.

  31. anzan Says:

    Our main production boxes run 8.04 LTS. Laptops and Eees run 8.10, from a month or so after it came out. I’ll dist-upgrade one production box to 8.10 a few weeks after 9.04 comes out and a laptop to 9.04 to see how it goes.

    Although upgrades from 7.04 to 7.10 went well, our upgrades from 7.10 to 8.04 were disastrous for using the LAN.

    I think that putting the most emphasis on LTS or meta-releases and putting forth intermediate releases, which are generally more like “Service Pack” releases of bugfixes, as, well, intermediate releases which are mainly bugfixes will present a quality of stability and dependability to users.

    Anyway, thanks Mark and to all for your good work.

  32. Scott Lavender Says:

    Interestingly, I really do not want Ubuntu to evolve too much.

    Why? I use Ubuntu Studio to record music. This means I use 8.04 LTS and crave not only stability but consistency.

    I enjoy investing my creativity and experiences into music rather than rediscovering my OS or my methods.

  33. Shuttleworth: cicli di rilasci lunghi sincronizzati « pollycoke :) Says:

    […] questa riflessione pubblica valuta i rilasci lunghi, con tanto di esempi alla mano completamente fuori luogo ma tanto popolari: […]

  34. Timo Aaltonen Says:

    I’m in favor of the 2 year LTS cycle. I’ve been rolling the X.0X releases out since dapper, because here in the university it’s only been possible to during the summer, and having to roll out an LTS+1 release doesn’t sound too assuring (they tend to be more on the edge than the others). But I guess it’s the same problem for the folks in the southern hemisphere..

    Admitted, I’ve had to roll out jaunty on a bunch of machines on February, because hardy doesn’t support the hardware. It turned out to work pretty well, so having a beta X.10 for the first two months in the fall semester might work after all 😛

  35. washburnello Says:

    While I’m new to the Opensource Comunity (3 years) and mostly just a user, I think having a Grand Release (it just sounds good) is a fantastic idea. I wouldn’t call regular releases “service packs” just because i think it steals their thunder a bit and makes them sound less important than they are. Now these names are just my opinion and mostly based on what i think sounds good.
    I see the value in having a Grand Release Cycle. It would give a good place for dynamic changes to the User environment to happen in. I think it might also help us to “lead the way” because big innovation almost always presents changes for people to get used to. It’s that clean break you were talking about. It’ll also create a lot of buzz having a 2 year Grand Release.
    Sorry for the long comment. Keep up the fantastic work and I’ll help where I can.


  36. Alexandre Franke Says:

    Some distros have rolling releases. Have you thought about what this can bring to users?

  37. drakshug Says:

    I much prefer the rolling release model which is a bit akin to the idea of a meta release – one solid distro with updates leading to a brand new release in a two to three year time period, a release that can be said to be brand new. The six month model leads me to playing catch up when I’d rather just sit with a distro that works.
    Even MS managed that with xp. That has been going for about 8 years with three service packs (upgrades).

  38. Michael "Rolling Release" Howell Says:

    Rolling releases are pretty cool, though they would need some sort of “Gentoo-ish” “masking” (for lack of a better term) support in apt.

  39. Scott Ritchie Says:

    It’s worthwhile to talk about deliberately less-stable releases as well. Wine uses a two week cycle for “development releases”, that are essentially just betas. But on Ubuntu alone they’re used by 135,000 beta testers. These users benefit from the short release: they can plan on being able to submit a regression bug report and usually have it fixed within the next two weeks.

    At Wine, we prioritize regressions. They’re much easier to find with a very short release cycle, and in many cases developers can learn about wrong code within days of writing it. That makes regressions easier to fix, too; it also makes being a beta tester much less painful, as things don’t remain broken for long. No patch gets committed without passing our (incomplete but growing) test suite. More on my blog here:

    Now, this might not be workable for other projects, since maybe they don’t want to prioritize regressions or care about backwards compatibility. And we’ll still need to freeze the code and do more extensive testing to make the next stable release sometime before October (Wine 1.2 will be in Karmic). This leaves some major new features away from users, waiting in git branches – the kinds of features that KDE targeted for KDE 4, causing lots of regressions with the 4.0 release. These features are important – the DIB engine in Wine would cause massive speedups for 2d applications ranging from AutoCad to starcraft. However, they’re known to cause regressions in a few apps, so they won’t get merged until they’re working right.

    I’m not convinced it’s worth breaking things for users by putting things like the DIB engine in before they’re ready, even if that means the DIB engine development gets slowed down a bit. Sure, there’s fewer people testing it when it’s in its own separate branch, but if they and the test suite aren’t finding any obvious bugs then it’s about time for it to be merged in anyway.

    Now, I could be mistaken, but the Wine philosophy seems pretty close to the Ubuntu philosophy – we’re not going to label another release stable until we’re confident that it is no worse than the previous one in all use cases. Sure, we’ll make development releases (Ubuntu alphas and Wine point releases), but we’ll make it clear you might face a regression so you know what you’re getting in to.

    It’s worked well so far. The DIB engine is still being developed, separate branch and all, and will be merged in at some point. Meanwhile, current users don’t have to worry so much. Maybe Wine 1.2 will come before the DIB engine is ready – but that’s ok, we’ve got other important features in git branches waiting to get out to users as well. Or maybe Wine 1.2 will be delayed specifically for the DIB engine – that’s the right approach if it really is “essential”.

    But we should be careful not to label so many big new features “essential” to the point where we delay a release forever or put them in, regressions and all. I feel that’s what happened with KDE 4 – it’s as though the developers said that the current desktop isn’t useful at all unless we get all these new features in. Meanwhile, there were tons of 3.5 users not using those features and doing useful things with their desktop; when they upgraded and couldn’t do those things any more, they very rightly got upset.

    Perhaps these users being upset is a good thing – it means the project actually has users who had something to be happy about before it broke. But I think that’s the case with all projects making serious decisions about time-based releases and long-term meta cycles. If you don’t have users yet, you don’t have to worry about regressions, and the release process doesn’t matter.

  40. bastianazzo Says:

    Which release in the major cycle is best for long term support? Is it the last of the releases before major new changes begin (Python 2.6? GNOME 2.28?) or is it the result of a couple of quick iterations on the X.0 release (KDE 4.2? GNOME 3.2?) Does it matter? I do believe that it’s worthwhile for upstreams to support an occasional release for a longer time than usual, because that’s what large organizations want.

    I can just answer this… the best for long term support is for sure the last of the releases before major new changes!! Companies and LTS user don’t generally care about innovations that much, if the tool is ROBUST! Give us Gnome 2.28, KDE 3.5.9, Python 2.5 (not even 2.6, look at how many scientific tools are based on Python 2.5) and Windows XP SP3, and we can work without silly interruptions! :) Thank you

  41. Lea Says:

    A meta-cycle doesn’t have to contain the word “cycle”; it could be called a “wave” or a “loop” for example.

  42. drakshug Says:

    You can delete this comment.
    How did akismet see my comment as spam?
    I brought in a comment about rolling releases, first to do so, and it gets held up. No spam, no expletives, no fragging? Pathetic. What is the point of commenting.
    from a long time open source user.

  43. Tim Kosse Says:

    From personal experience, 2-3 years seems doable. It is a long time though and a lot of things can happen during that time. To be on the safe side, I’d prefer longer major cycles.

    I’m the main developer behind the FileZilla FTP client and server. In fact I’m the only developer, unfortunately I could never attract additional developers for my project. (My code must be really repulsive ^^) I’m doing fairly regular releases of the FileZilla client, currently roughly one release every month that adds new functionality. It should be noted that I am not following any schedule, I primarily do releases whenever a bunch of new features are finished, just happens to be monthly.

    Originally the client did only support Windows and used the MFC library, now termed the 2.x branch. Early in 2004 I eventually decided to rewrite the client from scratch in a different, cross-platform toolkit, eventually becoming FileZilla 3. One of the reasons for the rewrite was that it became more and more difficult to add new features and releases became less frequent. The internal architecture of FileZilla was created early in 2001 when my skills as developer were still somewhat limited. Essentially, my very own code started to block my way.

    Initially I didn’t think it would take very long to rewrite the client, I didn’t know how wrong I was. It took me two and a half years to even get the first beta out, add another year until the first stable release near the end of 2007.

    To my defense I worked on both the old code as well as the rewrite in parallel for about 2 years. Fixing bugs in the old version and backporting a few improvements I learned along the way during the rewrite. And even after that I did occasional releases of the old 2.x branch to fix bugs.

    I think that’s the biggest problem that is often overlooked. If a developer says “2 years” then he means the time it would take if he would exclusively work on the new stuff. In reality however much time is always spent on maintenance of the old code, fixing bugs, crashes, security vulnerabilities or even adding a few features. During the transitional period a developer’s attention is easily divided between the two branches.

    This become problematic if there are tight schedules. Take KDE 4 for example. During its development and after, there still have been additional KDE 3.5.x releases. In other words developer attention was divided between 3.5 and 4, instead of working on KDE 4, some time was spent on improving KDE 3. The way I see it, it’s one of the reasons why KDE 4.0 was quite a disappointment for many users, more like a tech demo than a finished, fine-polished product. Since then, many things have improved in KDE 4.2, though I think it still feels rough around the edges, but it’s coming along nicely.

    After talking about software so much let’s consider hardware development. One aspect of hardware development is that you create a product and once it’s finished you move on to something new. Sure there are sometimes multiple hardware revisions of a product, but by far not as numerous as with software versions. The reason is simple, even if neglecting design costs, hardware is hard to manufacture and distribute. Once the hardware is out of the door, you generally cannot fix it anymore. Software on the other hand is trivial to distribute. Should there be problems with the actual hardware, they can often be worked around with firmware or driver updates, which are nothing else than software.

    I think this neatly explains why major hardware cycles are shorter than major software cycles, fewer developer resources are tied up in the maintenance of old products.

    While software developers tend to consider maintenance to a degree, they often vastly underestimate the time they eventually spend on it. In other words, the time for major cycles should even be larger than what the developers anticipate.

    Yet another problem is the the length of the cycle in itself, a lot of things can happen during that time. For example, do you know which personal issues will affect you two years from now? This is especially a problem in the Free software world where many contributes invest their own spare time.

    Last but not least, cycles between different projects cannot easily be synchronized unless you’re willing to risk many delays because some dependency isn’t finished yet, potentially causing further downtime in other related projects. As an example see X.Org Server 1.6 which got delayed and as result the proprietary drivers for ATI/AMD graphics cards still do not properly support it. Since Ubuntu 9.04 did not get delayed in turn it suffers from poor (or nonexistent) 3D acceleration on Radeon cards, which used to work fine in 8.10. Not really anybody’s fault in particular, it’s an inherent problem with unsynchronized release schedules. Fortunately Ubuntu is on a bi-yearly schedule, the situation would be far more dramatic on longer schedules if there’s a regression with some releases.

    To cut a long story short, the length of major cycles is irregular, often exceeding expectations. Tight schedules can easily result in a rush towards an inferior, unfinished product imho. The longer the cycle, the more finished the resulting product will be. However, to please end-users, the old products need to be maintained as well with frequent updates.

  44. anzan Says:

    “Would it make more sense to stagger long term releases based on how they depend on one another, like GCC then X then OpenOffice? Or would it make more sense to have them all follow the same meta-cycle, so that we get big breakage across the stack at times, and big stability across the stack at others?”

    No breakage for major releases (LTS or meta or main or whatever they are called. At all. Really.

    I have an Eee with 8.10 that’s been up (sleeping mostly) for 159 days. It’s ready when I need it, for the few minutes I do.

    Boxen on a LAN need to be able to do what they are being used for, and for that to happen with a LTS version is not so good. We almost abandoned Ubuntu for Debian because of this.

    (On the other hand, breakage caused us to discard GNOME with 8.04 and learn how to configure Fluxbox with Gtk apps and useful GNOME things without the complexity of a pile of services and crosstalk between applications and move more to CLI tools so I’m grateful for it but it’s probably not a feature for most people.)

    Also, I cannot in good conscience distribute install CDs to people with an OS that is creaky. We’ve distributed hundreds of CDs (a few from Shipit, more burned) but I cannot see doing so again until we’ve tested a release ourselves.

    So, really, stability matters.

    Again, thanks for your generosity and work and to Developers, Developers, Developers. And Maintainers, Maintainers, Maintainers.

  45. MikeMLP Says:

    Mr. Shuttleworth, isn’t one underlying goal of your inquiry here that the community collectively standardize on a single base set of releases of various core software projects, a single major ‘platform version’ that changes every few years, so that potential new users, including individuals, businesses, and governments, as well as 3rd party developers can more easily figure out what Linux is, how to benefit from it, and give back to it? Or is the goal a little less broad and more Ubuntu-specific / ad-hoc?

    If the former, I think that the creation of a single “core platform version” could also be an opportunity to focus the innovative energies of the community at large towards more well-defined goals relating to development for specific sets of potential users – something that each distro could benefit from. In fact, if such an organizational feat could be accomplished,there would probably be more quality distros competing for very specific market targets and competing on support services – the business model that the free software stack operates upon right now, only on a more vigorous level.

    I think version standardization of the core stack, development of a quick and simple marketing statement, and a single web portal for the stack as a whole to which potential new users and 3rd party developers could all be sent are essential if meteoric growth in Linux platform market share is to occur anytime in the near future.

    Un-jokingly, I say that the community should follow the footsteps of Microsoft in terms of providing, with a single voice, one major version of an easily-accessible stack of core software. Add the community’s responsiveness, continue with predictable time-based releases, and it could be a recipe for success on bug #1.

  46. Walther Says:

    Major and minor sounds fine to me (you’re using it already).

    Using the X.1 for an LTS sounds good, but it also has some problems. It usually means that most of the bugs have been taken out, but it doesn’t mean that everything that depends on it has been ported yet. For example KDE 4.1 is out but a lot of Qt applications still use Qt 3.x
    The same goes for the X window system and 3rd party drivers.
    It may be better to let the LTS be the last version before a major overhaul. You will get stability and consistency. LTS users generally don’t (or shouldn’t) care about running the latest software. The release after the LTS can be edgy and will only be used by people that don’t care about a little breakage.

    I don’t like the idea of staggering releases based on how they depend. It will take a long time for features in the lower levels to come to a distribution.
    You could give them a little lag (like between GNOME and Ubuntu), but then you lose the advantage of everybody having the same release cycle.

  47. Deepank Says:

    I believe that for large projects like distro releases, the release cycles should be larger. This will provide enough time to make big bets and to work towards achieving them. There will also be time for the marketing and adoption of the product.

    Usually, Ubuntu makes quick 6 month releases and that is fine, since it is a tradition for Ubuntu. But maybe the internal organization of the team should be such that some of the core competent developers should focus only on the LTS Releases and these releases should be marketed seperately by the team. Maybe a name change of the LTS Releases should also be done…

    Also, I do not believe that there should be a release with lots of new half-baked features, they might hold well with developers but won’t work with the real users. This happened with Vista and it happens with a lot of open-source projects, where people end up saying-“Hey open-source is just not good enough”.

  48. Joe R. Says:

    Mark, isn’t one underlying goal of your inquiry here that the community collectively standardize on a single base set of releases of various core software projects, a single major ‘platform version’ that changes every few years, so that potential new users, including individuals, businesses, and governments, as well as 3rd party developers can more easily figure out what Linux is, how to benefit from it, and give back to it? Or is the goal a little less broad and more Ubuntu-specific / ad-hoc?

    If the former, I think that the creation of a single “core platform version” could also be an opportunity to focus the innovative energies of the community at large towards more well-defined goals relating to development for specific sets of potential users – something that each distro could benefit from. In fact, if such an organizational feat could be accomplished,there would probably be more distros competing for very specific market targets and competing on support services – the business model that the free software stack operates upon right now, only on a more competitive level.

    I think version standardization of the core stack, development of a quick and simple sales message, and a single web portal for the stack as a whole to which potential new users and 3rd party developers could all be sent are essential if meteoric growth in Linux platform market share is to occur anytime in the near future.

    In all seriousness, I say that the community should follow the footsteps of MS in terms of providing, with a single voice, one major version of an easily-accessible stack of core software. Add the community’s responsiveness, continue with predictable time-based releases, and bug number one might be fixed.

  49. Skripka Says:

    One thing that has forever bugged me across OSes and over the years: was having to root-canal my OS to get the “new” and “improved” one that will work with newer apps. It was also one of several things that won me over to Arch from *buntu. There were other matters, but those aren’t salient to this discussion.

    This whole dilemma stems from monolithic release timetables. Of course, I doubt that Ubuntu will over go to a rolling release model-I also don’t think it should (for reasons of catering to users new to Linux)

    If one has a rigid monolithic release structure in mind-no matter what you do, you’re going to annoy some people some of the time. Either devs could use more time and users have to reinstall more often–but new apps are available sooner…or devs are happy, but users don’t get the new apps soon enough. Who do you try to please?

    You also can try to take into account other major software monolithic releases and sync things….but no matter what you do-you’re not going to be able to catch all or even a majority of them. This is the fundamental wrinkle or flaw in the Linux development model-with lots of decentralized projects unable to coordinate it is inevitable.

    Also regarding Gnome-MANY end-users seem perfectly happy with Gnome as it is (Go o’er to ubuntuforums), with no desire to have the wheel reinvented (as KDE did from 3.5->4.x). Whereas critics and new users will want or expect that level of blingy user experience. Who do you try to please?

    There really is no right answer for every user, every time. No matter what a balance has to be struck.

    Also NO software release has EVER been perfect and bug free at release *.0.0. No release of OSX or Windows or anything else that I can think of. You can strive to make it so–but odds are any time table you had in mind will vanish, in attempting to make things “perfect”.

  50. Flavelle Ballem Says:

    It seems to me that there are significant benefits to both long-term and short-term strategies, and no reason that a strategy to incorporate both cannot be managed.

    Consider the short-term, which I would suggest would be called a ‘release’. One of the nagging things about Windows is that when you obtain the operating system, it is a snapshot at a point in time. Same thing when there is a release of ubuntu. The problem with Windows is that the snapshot is changed every 2 – 3 years. If you obtain your snapshot after 1 year, or later, you are going to be spending a long time getting updates after installing the snapshot. The last time that I installed Vista, the updates took more than 2 hours to obtain and install – and this was on a high speed line. One of the big advantages of ubuntu is that with a six-month release cycle, the updates are much shorter. In addition, you get a new snapshot every six months, if that’s how you wish to proceed.

    The challenge with a release cycle of six months is that not everything will be synchronised. I remember the bruhaha surrounding the fact that ubuntu 8.10 did not include OpenOffice 3.0 – and I was firmly in the camp that said it should be there (it’s one of the core applications, along with Firefox, in my view).

    I use, and I like, GNOME and I am frankly dreading the changes to GNOME 3.0. Where something this large is happening, a longer cycle, which I’ll call a version, is mandatory. Following the KDE 4 saga was painful, and I’m sure that part of the pain is that KDE 4.0 was released before it was ready – probably in response to pressure to include it in the release cycle of the major end-user distributions – ubuntu, fedora, and opensuse – all of which seem to operate on the same six month cycle. GNOME 3.0, as a new version, should be treated separately from the release cycles of the various distributions. Working with the distributions, the GNOME team can provide a path to optionally install the new version as it is developed, until such time as it is stable, at which time, it can become the default for the various distributions that use it. In this way, for example, KDE 4.0 and 4.1 would have likely been optional installations for the distributions, with KDE 4.2 being the default for those distributions that use KDE. In my opinion, I don’t think that GNOME 3.0, or projects of similar size and impact, should be tied to release cycles (the short ones) but should be managed as versions (longer term, maybe 18 months to 2 years).

    A side note – one of the major reasons that I moved to ubuntu was Office 2007 – I was an expert in the previous versions of Office, but the interfaces changed so much in Office 2007 and I just couldn’t get comfortable with those changes. OpenOffice ‘looked and operated’ in a similar fashion to the old Office versions. Once I made that leap, I looked at Linux. I tried kubuntu and found I didn’t like KDE at all. I tried ubuntu and really came to like GNOME. Please don’t change GNOME simply for the sake of change, but remember that there is a large user base for whom GNOME, as it exists, works incredibly well! For this reason, if there are compelling reasons to change then the changes need to made slowly so as not to alienate the current users. There should also be very little pressure to incorporate GNOME 3 into a specific release of distribution.

  51. antistress Says:

    Ubuntu 8.04 seems already old to me therefore i think that i’m in the 2 years camp

    3 years would mean still having Ubuntu 6.06 today. Is someone running Ubuntu 6.06 today ?!

  52. Max Kanat-Alexander Says:

    Yeah, I agree with the above, major and minor cycle would be the most intuitive, I think.

    I think you want to stagger the cycles, because you don’t want everything to break at once. When everything is broken, it’s hard to tell what broke–you need to have some things stay still so that you can tell when other things are moving.

    What we’re doing for Bugzilla is we’re defining a roadmap for features that we want to see in our next “major” release, and then doing time-based releases until we get to the feature set that we wanted, and then we’ll call that “Bugzilla 4.0”. That way it doesn’t put a time limit on the feature set, but it does get out regular releases with incremental improvements in the mean time.


  53. IRC: #boycottnovell @ FreeNode: April 17th, 2009 - Part 2 | Boycott Novell Says:

    […] OT:… […]

  54. ek kian Says:

    one thing that i really want from meta-cycles is compatibility.
    shorter or longer meta-cycles is no problem as long as compatibility is maintained and when compatibility is broken, then must available a tool to do upgrade smoothly and automatically (but there is also have a option to revert back to old setup if upgrade process is failed).

    last time, i have difficulties installing Firefox 3 and Gimp 2.6 on my Ubuntu 7.10 and 6.06 installation (but they are easily installed under Win2k that 9 years old OS), why i must use backports repo for using latest apps using my older Ubuntu installation (and many latest apps is not available at backports repo)?

    i still using older Ubuntu because the OS is working ok, and if i upgrade it then i must checking everything again (i read many bad experience when doing upgrade and many gave advices to do clean install but i don’t want to install and setting my desktop every 6 month or even for every year)

    imho each OS version should have a life-span at least 5 years, this will give enough time for apps developer to create apps, testing it, fixing it bugs and improve it for that version of OS. Big selection of stable apps for that OS version will make the OS become a stable platform and not a moving target.

    i understand that for the earlier version of Ubuntu, there was many things changed rapidly that not compatible for each version but lately Ubuntu is starting taking shape, Ubuntu should gives more attention to compatibility between each releases.

    imho for each 6 month release should be looked more as “service pack” (minor release) rather than “new version” that contain only bug fixing with still maintain compatibility with all latest apps and then for each 2 years release, this is the actual “new version” (major release) that contain new major improvements.

    i really glad if for each new version of Ubuntu, live CD be able to detect the existing version of Ubuntu on hdd and asking about upgrade it or do fresh install, if user choose to upgrade, installer will backup all the old system files and settings, and replace it with newer system files and newer apps but still maintain old user settings, after that user can try the new upgraded system, but if user not like it they can revert back to old system.

    Thank’s Mark for the great efforts and commitments thru Ubuntu to bring the best desktop user experience to Linux. (sorry for my limited english :)

  55. Novell Won’t Coordinate Releases with Canonical/Ubuntu | Boycott Novell Says:

    […] two years ago, it was surprising to find that Mark Shuttleworth had negotiated with Novell, but according to his latest blog post, it fell through. Six-month cycles are great. Now let’s talk about meta-cycles: broader release […]

  56. anzan Says:

    Two years, please.

  57. Shane Fagan Says:

    I think Ubuntu has a good system going give the updates and the new features on a 6 month cycle. For components it would be better if it was staggered, it saves the all the distros from major bugs across the board. I think that major releases like Ubuntu LTS are needed to keep people new to free software comfortable because its similar to the microsoft and apple model of putting out software. Its interesting how Gnome is being developed because it seems like they haven’t really done anything major in a long while. I was glad to hear that they announced Gnome 3.0 and the major changes they were hoping to bring in like replacing gnome-panel with gnome-shell. I think that KDE 4.0 is very nice looking and this pushes Gnome to change how it looks.
    What do you think of the plans to shake up Gnome?
    Also what would you say to merging totem and rhythmbox?
    I think that they should be merged to make both of them better, at the moment totem doesn’t support libraries, it just has a local search.
    One last question is there any plans to make Evolution more user friendly or at least switch it with thunderbird?

  58. stuphi Says:

    In my head, the big change should be the first release after a LTS release. If lots of projects could synchronize with that, then that would be fantastic. I really like what you are doing hear to try and push this forward. One problem I could see is if lots of the major projects that make up a modern GNU/Linux system were to change simultaneously, would a distribution builder be able to cope?

    Well done for all the hard work you and your team does for the community.

  59. Czubek Says:

    I just want to say, that 6 months release cycle with 18 months support and 24 months LTS with 36 months support are fine by my count.
    I use latest stable on my computers, and I like it. But if I see that someone is less computer comfortable then I recommend LTS release for them. Once installed, configured and patched and they with some luck will not need help for another 2 years. For example, my parents use 8.04 and they know how to send-email via Thunderbird etc. And I will not change version of Ubuntu on that computer until another LTS. For them, even a change of location of icon/program could be very confusing, although I think they could survive my quick adaptation course once a 2-3 years 😉

    Thats my 0.03 $

    ps Thanks Mark and all community for good work to bring free software to normal people.

  60. Jose Ignacio Marín Says:

    Waiting for Tcl 9.0 !

  61. Michael Glasser Says:

    Good to hear such thoughts. I am not sure what the best schedule is, but I would say that a consistent schedule is a clear benefit to the user and to the developer… though consistency here is not *as* important as consistency in other areas, such as UI / usability issues.

  62. zelrik Says:

    I am thinking that a flexible release cycle length would make sense. This would be of course a multiple of 6 months. Every 6 months there would be at least minor updates and fixes but not necessary a full blown upgrade :

    Let’s say:
    10.10 M
    11.04 m +LTS
    11.10 M
    12.04 m
    13.04 M
    13.04 m +LTS
    14.04 M

    Where M stands for Major and m for minor. so there are still well defined milestones but . I would delay a LTS by at least 6 months after a Major release so that you can focus on bug fixing,removing regressions during those 6 months. We could even skip minor releases to focus on major ones, but this would need to be justified I think… so it would be like semi-incremental with some long term projects in between. A ‘M’ would mean ” get excited ! We are doing stuff!! “, and ‘m’ would mean ‘ get excited!! we are fixing stuff!!’. I think that would provide also better cooperation since you can try to synchronize with other projects when it makes sense.

    My 2 cents…

  63. Adam Says:

    Business and home users will be at odds over this, I think. As an enterprise user of Ubuntu (and many other OSs), a very long release cycle is highly beneficial to me, and to my software developers. A stable, not-moving-much development target is crucial in large software developments, but even more so in large software deployments. I’ve done deployments of software (granted, to Windows…) that have taken more than a year to complete, due to size and organizational restraints.
    When you branch out of private use and into government (US govt, at least, in my experience), ANY change in the OS is going to cost a few months at minimum for retesting and paperwork purposes (the DOD is especially bad about this).

    On the other hand, the rapid update cycle makes my life as a private desktop user much more fun – every few months I get a bunch of shiny new toys and updates, and it definitely helps keep me interested.

  64. Matthew Gaunt Says:

    I think this is a really interesting topic, I faintly recall reading a blog post discussing your (Mark Shuttleworth) idea of several distributions releasing versions at around the same time to share fixes and patches.

    It’s an interesting idea to have short releases along side longer releases because as you said, longer release means you can make a fresh start, which as many people can imagine means developers are free to add in anything they wish as there will be no dependencies to deal with the current design of the program, and any bugs in the new release can be ironed out in the short term releases.So this prevents us from seeing the same thing over and over again with updates but just slightly more efficient and/or less bugyy.

    The only thing I can see being a problem with this approach is if one bug is fixed in one release of an application, what stops this bug being re-introduced if the application is re-written for a larger release?

    In terms of the staggering of hardware and software is hard to say and the way I would view it is if they are both released at the same time, we will either get none of the new features or get a buggy implementation, which if the second option occurs, average users won’t upgrade and the more involved users will upgrade find the bugs and make the fixes, which could be a good thing encouraging users to help out the project, but bad if you want a good experience for an everyday user.

    If you stagger, it gives the project time to implement and test the new features before releasing.

    + another 2 cents :-)

  65. Dim Says:

    Let’s not forget that short cycles (like 6 month cycle for Ubuntu) are great for marketing. Each time a new version is released it hits top technical sites so that Ubuntu gets more converts.

  66. Joe "Floid" Kanowitz Says:

    There are a lot of catch-22s involved in focusing so intently on “cycles” here. A “major” release (LTS, ‘major cycle’) “can’t” come out broken, so you want to force everyone to build/test/eat-own-dogfood early and often (every 6 months)… at which time major releases stop looking so major, unless you then advocate people throwing away all the benefits of incrementalism to do something new and special to launch a new “major cycle.”

    I think the gut assumption behind Ubuntu’s initial “major cycle” was correct — LTSes should just be “tags” placed at chronological intervals, with knowledge that, at that interval, whatever dogfood exists should be made as edible as possible because people will be trying to live with it for the next N years. I also advocated cherrypicking LTSes late, which actually isn’t incompatible with that — since there are [presently] two releases in a year, you would simply spend two releases with everyone extra-aware of stability and QC, instead of one, and acquire 6-12 months of real-world data about which would make the best LTS/is least-unbaked.

    Meanwhile, as a normal human trying to work with this stuff, I have to admit that the 6 month cycle has quickly led to “patch fatigue” — 6 months is just long enough to get a good impression of what’s working, what needs workarounds, and what’s been completely counterproductive [when trying to use the desktop natively in a SOHO environment]… there’s a limit to how much local configuration I dare perform when knowing a dist-upgrade is likely to blow it out in 5..4..3..2..1 months. Big, “enterprisey” entities have gotten so used to this that they now treat the “desktop” as only a “browser” for the “web” or “cloud” or whatever we’re calling it these days; this works, but I still wish we could do better and not penalize local autonomy. [To really address this, the problem would have to be attacked from multiple angles — for instance, update-manager needs to be able to diff anticipated changes in /etc *before* an upgrade so an admin can prepare without babysitting an entire install… attention also needs to be paid to binary compatibility across releases, which is always contentious. There are third party projects to help with this sort of thing, but I haven’t found time to evaluate and apply any when most of my scant “admin” time is spent keeping an eye on Ubuntu itself!]

    Finally, with thinking being so “cloudy” lately, one major modern luxury shouldn’t be overlooked: As recently as 5 years ago, “most” resources on a desktop machine were devoted to running the OS and desktop environment. These days, even the least expensive hardware [excepting the “retro,” “sometimes-you-*really*-only-need-one-core” approach of LPIA] can comfortably support two or more instances of an OS at once, so… as a thought experiment, having one “Preview” release and one “Real” release per year would not be so painful (assuming it’s possible to promote consensus on which is which!). Thus, dogfood would continue to be eaten every 6 months, but the “Preview” would be suggested for developers to bang on in a VM, serving as an extended alpha of sorts, and the “Real” release would thus stay stable and supported [with security/stability patches, but no ‘disruptive’ changes] 6 months longer than presently, giving people more time to *use* their machines between upgrading them.

    I’d like to wish that a slower-moving treadmill would be “just enough stability” to help attract developers of specialized application software, under the assumption that it takes at least a year to reach 1.0 of anything complex — note that *NIX still doesn’t have anything quiiite like Quickbooks available non-server-side, let alone legal billing software (a personal holy-grail at my workplace right now). This might be a pipe dream, since, despite market share figures and diversity of implementations, *NIX’s audience still seems much more homogeneous in certain ways (subject-matter experts who are well-served by incumbent platforms have no reason to look in our direction, and probably don’t see a financial incentive; Apple, in contrast, had the good luck to ‘pick some up’ in the industry’s formative years and has managed to retain them). But at least this immodest proposal doesn’t *actually* change the 6-month cycle for anyone other than those wishing they could stand still for 6 more months!

  67. Nicolas Bonnici Says:

    I just can’t wait to try a new release each 6 month on my laptop, since the 6.06. Gnome is a quite simple GUI, everything goes easy for mostly users, i just switch Evolution with thunderbird. In all case the look and feel of the new notification system is pretty cool such as tools like Gwibber or the handle of 3G keys.

    This Linux distro is the key :)

  68. guido alexander waldenmeier Says:

    howdy hi there or whatever 😉
    for private use is a half year ok
    thats fine

    but companys need a half years for the plan what she want to do ;o)

    so they need longer terms

    more time for meetings and daily bla bla


    so 2-3 years are ok

    greetings from southwest germany near stuttgart
    and a nice sunday all


    and by the way

    you need long term support to
    it s a long jorney to the mars ;)))
    gotscha baby 😉

  69. » Shuttleworth: cicli di rilasci lunghi sincronizzati Says:

    […] questa riflessione pubblica valuta i rilasci lunghi, con tanto di esempi alla mano completamente fuori luogo ma tanto popolari: […]

  70. obrowny Says:

    First of all, sorry for my english. It is true that a 6 month cycle make people think nothing has really changed between the two versions. It is untrue as Phoronix has revealed almost a 50% improve between 8.04 and 9.04 ! This proves that in terms of technology, a 6 month cycle is quite efficient to optimize work but that it is unefficient in terms of customer’s perception (marketing). For Microsoft, there is a major release every x years and sp1; sp2… for optimization. This strategy is (for me) very efficient in terms of customer ‘s excitment as a new version of windows (or osx) is always a major event…
    So I really agree that meta cycle is essential for two aspects : Technically having a mid-long term goal is very important especially when linux distributions are a sum of small projects. Having an overall view make people row into the same direction. I feel it would be great for everyone to synchronize and focus on the same meta cycle for a bigger step.(Gnome, kde, ooo…) I am not competent enough to tell how long it should be…
    Then it is very important as well for marketing to create an excitment every x years with mysteries around it like Apple and Microsoft do (conferences; marketing events journalist appeal). We miss marketing a lot with linux distributions. We need strategy and coordination to improve now. I would like a name change as well so that you know instantly it is THE major version. For example you have “jaunty jackalope”, then “jealous jackalope”, “juvenile jackalope” and for the long cycle it becomes “Karmic Koala” and so on…Hey !! This is just a funny suggestion 😉

    final thought :
    Ubuntu is a lot easier for newcomers than windows (yes make the test and you’ll see). Now we just need the whole world to know that. We have to communicate on that.

  71. Stefano F. (tacone) Says:

    Why not setup a common (debian/ubuntu/fedora/suse/etc) forum to discuss this kind of issues ?

  72. Ole Eskildsen Says:

    I believe that a longer cycle (than the present 6 months) would be more beneficial. I would favour a cycle which is always targeted at the same month in the year, hence a cycle based on the year. I think 1 year would be too short and 3 years too long, therefore a 2 year cycle would be good, and, yes, that should therefore be the LTS version. I’m not saying this to mimic Mark, but I have for quite a while been thinking that this would be more practical than the present 6 month cycles. The 6 months cycles could continue, they would be particularly useful for developers and anyone else interested in following and trying out the “bleeding edge” of the software developments. I would therefore call these cycles: UBUNTU INCREMENTAL SYSTEM UPDATES.

    As the Ubuntu Linux family continues its meteoric growth in popularity and uptake in the community, I believe that by applying the 2 year cycle it would be easier to get cooperating software developers (including alert applications developers) to target these update cycles. Such updates would therefore likely be not just Ubuntu system updates but would also hopefully contain significant application software updates. Therefore, here is my suggestion for a name: UBUNTU PLATFORM UPDATES!

    Two year cycles would allow all developers including application developers, approximately 18 months to come up with their next major improvement and the Ubuntu team 3-6 months to finalize integration and testing to ensure that the next platform update will work flawlessly and contain substantial and noticeable improvements.

    From a user perspective this would provide IT managers and supporters and trainers ample time to get ready for each platform update.

    Thanks for the great family of Ubuntu Linux software, please keep up the good work.



  73. MikeMLP Says:

    I would have to agree with Stefano. Mark, it seems to me that your post rather detail-heavy when maybe the discussion should be a little more broad. For example, you’re asking how would project X fit into distro Y, and if any individual _projects_ have best practices for coordinating releasees. Suppose you find out that certain projects do, or, even more likely, that projects make major and minor releases whenever their communities and codebases decide that it is time to do so, and they coordinate with other projects through ad-hoc communication. What then? What is the next step? I think that’s a major question that your post leaves unasked.

    If everyone across the community can generally agree that bug number one is their primary goal, or, at least increasing linux platform marketshare rapidly is a shared fundamental goal, then why not try to get the great weight of the community behind a “linux core platform” idea – for the desktop, that would include the stack from X on down, a single package system, plus maybe a choice of KDE (pitched for programmers, enthusiasts and the like) or gnome (for government and business officeworkers)?

    I think the Ubuntu model of 6-month releases plus an LTS has worked well – There’s a reason why Ubuntu is a leader – customers love the predictability. Keeping the ‘customer satisfaction’ idea in mind, that should be grafted onto the release of a “linux core platform” by the community as a whole -eg: ‘these are the versions of these software projects that will be our baseline supported releases for the next 2-3 years, and we’re calling it ‘linux core platform 1.0,’ or something of that nature. Keep the 6-month releases for testers, enthusiasts, and for responding quickly to the competition, so that they never gets more than a 6 month window to have a feature we don’t have.

    This would accomplish two goals which have already been discussed here, both relating to fundamental weaknesses – balkanization / fragmentation.

    First, a core platform that the community pushes with one voice would greatly simplify the information gathering and marketing process to potential growth markets. Right now, every distro does that on their own, and each distro is relatively small. The message to potential customers is confusing, varied, and difficult to keep track of. What’s a Fedora, an Ubuntu, a Suse, a Red Hat? Why should I choose one over the other? I think that complexity turns a lot of people away. People want to know what they’re getting, when they’re getting it, and how it will make their lives easier. That’s all. If it is at all difficult to find that out, they’ll move on to someone who can make a better, simpler pitch.

    At the distro level, why not combine resources, working together on research and marketing for the linux platform as a whole, and devote yourselves to competing on services and specialty solutions for specific customers or groups of customers? Isn’t this your business model right now anyway?

    Second, if there were some ‘linux core platform,’ with a single message, and a community-wide release schedule that everyone was aware of, then that alone would be enough to kick the community’s focus into high gear. I think right now people don’t really know who they’re writing software for. If we could focus creative energy for certain groups of people, then we’d do a better job at giving customers systems of tools that work together, doing what they want when they want it. I don’t think individual project autonomy on releases would go by the wayside, but if everyone, say, had ‘what are we going to do for core platform 2.0?’ in their head, then that in itself would be enough to kick development up to the next level. And that’s really what you want, isn’t it?

    P.S. I highly recommend “Mastering the Dynamics of Innovation” by James M. Utterback, and “The Visible Hand” by Alfred D. Chandler.” Mastering, focusing, and driving the open source model is precisely what you, and a lot of other free software leaders and entrepreneurs are trying to do. No one’s quite mastered it yet, so that’s why I don’t think you’ll necessarily find any ‘best practices’ for what you really want to do.

  74. Ole Eskildsen Says:

    Why has my comment above
    “been flagged by Akismet as potential spam,” ???

  75. Jim Rorie Says:

    You have two competing goals in Ubuntu releases; features and stability. These are typically inversely related. Both are very important for the long term success of the distribution. Features are important for implementing the newest technology. Stability is what keeps users happy and establishes the Linux reputation, particularly in a business environment. I see two tracks based on these goals.

    Stability should be your pulse. Everything should be based around LTS to make supporting that release as easy as possible and to give the best user experience in the long term. Synchronization with debian, wine, gimp and openoffice would be of utmost importance. Whatever these groups need to achieve synchronicity should be accommodated, within reason.

    Features take a quicker track, being in multiples of 6 months depending on the level of complexity. The important part isn’t when you start, but when you finish. A two year cycle could look like this.

    Cycle Stability Feature Set
    LTS Ultra-stable Stability Support Only
    LTS+1 Stable Maximum Technology
    LTS+2 More Stable Opportunistic Changes
    LTS+3 Very Stable Minimal Changes

    Disruptive development should be targeted to LTS+1 to give it the longest possible testing cycle before the next LTS. If that technology misses it’s deadline, you can retarget it for LTS+2 but no further. Also, a new naming concept should be established for the LTS+1 reflect it’s new technology focus, such as Technology Rich Release (TRR) or similar concept. The concept of a technology preview should be avoided as this would give the impression of a beta release.

    LTS+2 and LTS+3 would reflect the technological flow of the community. LTS+2 would consist primarily of opportunistic changes to the distribution and a focus on bug resolution. It could serve as a defacto point release for LTS+1.

    LTS+3 could have a particularly interesting purpose by focusing on non-technological changes to the distribution, such as graphics, themes, translations and documentation in addition to bug resolution. The graphics and sound tweaks would give users something tangible to grasp. The Internet community as a whole could be included by incorporating “contests” of sort to judge new wallpapers, sounds etc. This media would have to be creative commons licensed and users could vote on what to include in LTS+3.

    LTS+1 branding should also reflect the pioneering nature of the release. The naming concept should reflect its wild and woolly nature; Loopy Loon, Manic Macaw, etc. Something that lets people understand that it’s definitely Ubuntu, but the training wheels are off. This is important to set users expectations appropriately.

    There would be marketing potential based around this type of release cycle. You immediately have the buzz of a stable release, which will be of interest to the business environment. This will be followed 6 months later by the interest in the general community for the technology release. If sufficient interest in the open arts community could be generated, then there could be significant interest in LTS+3 as well giving a lead-in into the next cycle LTS.

    The one-two (-three) punch in this release cycle concept could server amplify interest in the open source movement. If this concept proved successful, I believe that other distributions would reassess their position on community synchronization.

  76. Jo-Erlend Schinstad Says:

    I think releasing an LTS every two years and supporting it for three is a good idea. That gives us early adapting LTS users and late adapting LTS users. When an LTS has been alive for a year, it should be stable enough for any usage. I also think it’s logical that the LTS should be the last release after a major change. LTS users want stability; not only that software doesn’t crash, but that the interfaces and features remain the same. This also gives us extra time to develop good documentation, tutorials, etc, to be ready for the LTS release. The early adapting LTS user would be greeted by an internet that’s already well educated in the usage of the system. From day one. I think this is very important. It’s easy to forget that most users doesn’t care about the bling and shiny; they want to do the things that they do, and they don’t want to re-educate themselves just to keep the computer safe. People are going to upgrade from XP to some other version of Windows, be it Vista or 7. But for most users, that’s only because it’ll be unsafe to use an unsupported operating system, not because of new features in new versions.

    I think we’re finally reaching a stage where the computer is actually meeting the requirements of the user, maybe for the first time ever. Is this the reason why people are still sticking to XP? I’m perfectly happy with the Jaunty Jackalope, and I mean that literally. There are some bugs, like Alarm Clock freezing the entire desktop, but I can live without that application. And bugs can be fixed. Feature wise it’s 100%, and I think I would like to use this version for the next ten years, but then I’d be using an usupported OS, which I don’t want to do. I’m dreaming of “Ubuntu XLTSior”; the last version of Ubuntu before the radical changes of the GNOME 3.0 desktop. This version would be supported for an eXtremely long time — maybe ten years, or even longer. To be able to buy a computer and have that computer work as long as it actually physically works, preferably. To be able to provide blind support (not seeing the screen) because I’ve been using the system for such a long time. _this_ is good marketing. I know people who are still using twenty year old television sets and vinyl players. And why not? It works, even if HDTV and Ogg-players may be better in some ways. Why should computing be any different?

    Long lived hardware coupled with long lived software, that’s something we need.

    Progress is good too, of course, and in some ways, I do miss the old days when I felt it necessary to upgrade Ubuntu every six months and get the latest features and fixes. In that regard, I’m really looking forward to GNOME 3.0. Rapid changes are good for developers and for those who are interested in the systems themselves — to keep the energy up — but they may be unnerving to the average user, and costly for big companies.

  77. BUGabundo Says:

    I would just like remember that Debian isnt at strict with dates as Ubuntu. So planning to do a common release by 10.10 may be a bust if Debian feels its not ready yet.

  78. Steven Says:

    I think a rolling release plus incremental true releases solves a lot of these issues (for a distribution). Keep a perpetual “development branch” (bleeding edge version) which is best effort but generally functional, along with an annual or longer stable which is supported for a period. Stable can be made from a periodic freeze of the development release to polish and flush out bugs. Large scale changes such as gnome3 should be developed independently of the main distribution and development cds until they are ready, maybe in a PPA or kept separate through other means (ubuntu-desktop contains the most up to date gnome2, ubuntu-desktop-3 contains next gen, in development gnome packages for example), features that aren’t ready should be kept out of the release entirely. Updates for application software should be semi-regular even in the stable system (after a testing period) or users feel they are using outdated software, which is a complaint you sometimes see with Debian stable. Core updates should be kept to a minimum. Bug fixes should be released throughout the supported period.

    Through this I think users that want to can keep their bleeding edge system, but the average user using the release is able to have a pretty predictable system, and up to date, not bleeding edge packages. Those who always want the newest and don’t mind lots of updates, like users of Jaunty throughout the alpha and beta period, can keep their lots of updates and experience changes as they happen.

    I do not think there is anything wrong with two development cycles, one for the release and supporting it and one for the new and improved next gen technologies that will eventually make it into the release. It is something that systems such as FreeBSD have been able to do successfully for quite some time.

  79. Flavelle Ballem Says:

    I’m wondering, based on some of the comments above, if an annual ‘release’ with good support for backports might be a good strategy? An example would be ubuntu 8.10 and OpenOffice. Devoting resources to a new release, and two code-freezes per year, seems to be causing more problems than it solves.

    If we went with 8.04 with Backports, then the resources that were devoted to 8.10 could have been working on incorporating the latest applications into the backports – such as OpenOffice, FireFox, etc. The 9.04 release could then incorporate the applications contained in the backports as part of that release. As I understand it, the reason that OpenOffice 3.0 was not incorporated into 8.10 was because it arrived too close to the code freeze. The frustration of knowing that OpenOffice 3.0 had been released, but was not being included in 8.10 caused a whole lot of noise. OpenOffice is considered by many of us to be as important a component as Firefox.

    Frankly, I could have lived with 8.04 with backports for OpenOffice 3.0, Firefox, etc. The backports were delayed because of the work being done to get 8.10 released. The backports would have to be able to properly update the original applications.

    Another commenter has suggested that Thunderbird, not Evolution, should be the default e-mail client. There are two things that Evolution provides that Thunderbird does not – an integrated calendar function, and the ability to hook into GNOME to provide alarms without actually running Evolution. I know that Thunderbird has Sunbird, but it doesn’t seem to be as tightly integrated. Consider that if I put a calendar entry in Evolution with an alarm, and the alarm time is reached, then a notification appears on the top panel, regardless of whether or not Evolution is currently running. I would want the same degree of calendar integration in Thunderbird before it became a default.

    Note that in Windows, if you set up an event with an alarm in Outlook, you do not get the notification unless Outlook is running. It’s a small thing, but is part of the superior user experience in ubuntu (or GNOME in general – not sure which provides the functionality). I would want the same thing out of Thunderbird before having it imposed as the default e-mail client.

  80. Wayne B Says:

    This is a “Damned if you do, damned if you don’t” situation, and no matter your final choice someone is going to hate it.

    That said, Ubuntu needs to keep the 6 month cycle for releases. Yes, there are problems (8.10 was a horror story with some hardware). For LTS releases I’d stay with every 2 years, but change the support period to 5 years, to give extra stability.

    As to trying to work with other projects, this sounds nice in theory, but in practice I think it would be a bad idea. Consider 8.10, it came with OOO 2.4, as 3.0 wasn’t released until a month later. With the huge number of important projects (Gnome, KDE, KOffice, OOO, VLC, Amorak, Linux Kernel, GIMP, Inkscape, QCad, Adium, Abiword, Vuze, Jahshaka, and on and on) I can’t see a practical way to coordinate things. This doesn’t mean it shouldn’t be tried (and that might make a great Free Software project in it’s own right – a Release Coordinator Tracking Tool), but that it can’t be relied on, because you never know when a problem might delay release of a package.

    I should mention that I’m not involved in any of these projects, except as a user, who loves Free Software, and prefers programs licensed under the GPL/AGPL/LPGL.

  81. anzan Says:

    Still, timing with Debian would be verybeneficial to both. If at all possible, delaying 10.04 to 10.10 or even 10.12 would be worth doing.

  82. sander Says:

    ==What about the following idea?==

    1) Keep the regular time-based releases (preferably synchronized with other projects)

    2) At the same time, introduce the meta cycles by starting a “sister project” that is developed at the *same* moment.

    3) Synchronize the beta releases of the “sister project” with the stable time-based releases.

    4) Popular new features in the “sister project” can be backported to the stable time-based releases.

    ==Example for the Ubuntu project==

    (If items have the same number, it means they are at the same moment in time.)

    1) Ubuntu 9.10 is released
    2) Development of Ubuntu 10.4 is started
    2) Development of “Ubuntu Meta” is started
    3) The beta versions and release candidates of Ubuntu 10.4 are released
    4) Ubuntu 10.4 is released
    4) “Ubuntu 10.4 A Look Into The Future Beta 1” is released
    5) The Ubuntu project gathers end user feedback, business feedback and press feedback from both software releases
    5) Development of Ubuntu 10.10 is started
    5) Development of “Ubuntu Meta” is continued
    x) Ubuntu y.4 is released (the last!)
    x) “Ubuntu A Look Into The Future Beta z” is released (last beta)
    x+1) Development of “Ubuntu Meta” is now continued as Ubuntu y.10
    x+1) Development of “Ubuntu Meta 2” is started
    x+2) The beta versions and release candidates of Ubuntu y.10 are released
    x+3) Ubuntu y.10 is released (a big change!)
    x+3) “Ubuntu A Look Into The Future Second Edition Beta 1” is released


    * Keeping the predictable time-based release cycle

    * Time-based betas for the Meta releases! (it also may be alpha if beta quality is not possible)

    * A little focus on stability for Meta releases too

    * Collaboration between sister projects thanks to synchronized releases (e.g. backporting features that became very popular, marketing leverage as the press can write about “The future of Ubuntu” in their reviews of a new release, parts of the operating system that are not planned to be changed in the Meta cycle can be maintained by the stable time-based cycle, and so forth).

    * The Meta project is a playground for creativity; the betas of the Meta project allows children to play on this playground (opportunity for much useful feedback)

    * The Ubuntu project is free to decide when the “Meta project” is ready to be released. Depending on the bigness of the big changes, this can be 1 year; 1,5 years; 2 years; 2,5 years; 3 years; 3,5 years; and so forth. In other words: although the Meta project will see time-based beta releases, the final version will *only* be released when it is ready. However, the decision about its readiness should be taken at least 6 months in advance of the release (if not ready, the development of a new time based release should be started). Also, if it is not ready, the soonest release date is 1 year after the decision of not being ready. This long period may be a huge driving force for involved parties to contribute more resources in order to get the Meta project ready for release (otherwise it will take 1 year longer).


    * Needs good management of developer resources; e.g. the time based releases have to include *new* *features*; they may not become bugfix releases.

    * Setting up a whole new sister project structure is a huge task, especially because links to the current time-based project are required.

  83. sander Says:

    Just a sidenote: did anybody noticed the release candidate of Windows 7 being synchronized to the Ubuntu 9.04 date with only less than 2 weeks in between? :o)

  84. Rich Says:

    @Glubbdrubb: “triple cycle” and “quadruple cycle” roll off the tongue better if you abbreviate them… “tricycle” and “quadracycle”!

    The major releases could be identified as “Milestone Releases”. It’s a term in common usage already, makes complete sense without introducing the term; and while not obvious, it also makes a lot of sense that a milestone release would receive long-term support.

    I disagree with zelrik that the LTS release should trail a milestone release by six months to give it time to stabilize. That is what betas and release candidates are for.

    Ubuntu would benefit greatly from synchronizing its releases with the upstream distro, so it would be fair to delay the next LTS to 10.10. The Debian distro and its team would also benefit in turn from Canonical’s guaranteed support. Synchronizing with other non-Debian distros? Not so much. I’m not sold on synchronizing Linux releases from different families: Slackware/SuSE and RHEL are entirely different animals, and both are distinct from the Debian derivatives. I see staggered releases of the very different distros as being a good thing that stimulates the other distros into action. When dates coincide too, that also provides some healthy competition. Fixing all distros into the same release schedule for all time would, I believe, curb the enthusiasm of some developers.

  85. A Canuck Says:

    The predictability of release cycles is more important to me then the timing. I hope Ubuntu does not try to time the next LTS release with a Debian release. The Debian project has never made a release on time. I love Debian. It is still my favorite OS, but at work I have switched to Ubuntu LTS. The predictability of releases has made it easier to develop and support our internally developed and used software. The versions of various libraries and other software such as Postgresql do matter. Software that was developed for Debian/Etch did not work immediately on Ubuntu Hardy Heron. Predictable Ubuntu releases allow us to better plan our release and testing schedules.

    It should not matter if the Gnome, KDE, gcc, and foo projects all adopt different major-minor cycles. As long as the cycles are predictable it should allow aggregate projects like Ubuntu to plan for what versions to include and when.

  86. anzan Says:

    Actually, Rich, Milestone Release or Edition does sound good for LTS releases.

  87. Ole Eskildsen Says:

    Here is another “potential spam” (?????) from me.

    RE: Release time frame!

    I would suggest that a spring (in the northern hemisphere, I’m down-under but don’t worry about me) release for the, say, bi-annual platform, milestone, major, or whatevery you want to call it, release, would be better than an autumn release.

    Why? Well, most developers live in the northern hemisphere (I believe), so the long, dreary months of winter for finishing the development and testing before release in spring, would be better than a few months after the summer holidays.

    I know this from practical experience, I have been a software development project manager for over 25 years. You will get the best effort out of people during the winter months.

  88. Igor Gomes Says:

    I believe that some sectors CAN take enormous advantage from the serial release term (SRT), and others MUST keep a preemptive release term (PRT). In order to keep the energy high (as you Mark said) longer and have a sustainable environment, we need some commitments and research:

    ## SRT

    1) Identify all project desirable term duration (variable from team to team, project nature etc.), fit them in some clusters: 1 month, 3 months, 6 months, 12 months, 24 months. As can you realize, all “fittable” on the following one.

    2) Get the teams’ commitments to follow its release cycle.

    3) Shift used releases in dependent projects (xorg_x using gcc_x-1, rubyapp_y using libruby_x-1 etc.)

    4) Continuous development of independent work (not related with external dependencies), but following the new-features/development-plan approved by the cycle’s begin by the team and an related external committee (invited) with impacted projects or brainstormed with users.

    ## PRT

    1) Here are all projects that its use implies in 0day-development or urgent matters. For example, as soon a new hardware is released, the kernel team should work. As soon a security hole is discovered, it should be fixed.

    2) PRT follows the SRT for major releases

    Independent of SRT or PRT, users will contribute like nowadays by testing features during the development or submitting upstream patches as happens with launchpad-ppa’s. Everyone has some or even dozens of ppas enabled for software that you like or see faster development or see a conservative approach from the distro.

    So, those are my few coins. I’m open to debate or further develop my ideas.

    Igor Gomes

  89. kikl Says:

    Just my 2 cents: From a user perspective many incremental changes are preferable to a few big changes, because it’s easier getting used to them. Therefore, I prefer the 6 month cycles. If certain changes need to be addressed over a longer period of time, this should be organized within Ubuntu without changing the external release cycle. Have a couple of programmers working on 2-year, 1-year projects and others work within a 1/2-year cycle depending on the particular project.



  90. Ole Eskildsen Says:

    @ kikl

    If you are already using one of the Linuxes from the Ubuntu family, then you can already get incremental updates from the Ubuntu team.

    As individual applications are updated or bugs have been fixed and tested to work with the Ubuntu family, then these updates are being made available for installation using one of the installers such as adept or synaptic. These installers do all the work for you, you don’t have to be a nerd to use them. They keep you installation up-to-date. These will continue to be issued in between the 2-year (or whatever period is decided upon) platform releases.

    On the other hand, the software industry is definitely not static. As new hardware features become available or new improvements in applications are developed, everybody wants to be able to get such changes. Wouldn’t it therefore not be much easier if these are collected together into periodic updates, say every 2 years, rather than having to make updates every 6 months as at present?

    You don’t have to be nerd to take advantage of such developments, they are actually meant to be used by the millions of non-technical Ubuntu users worldwide.

  91. mateo’s musings » Mark Shuttleworth » Meta-cycles: 2-3 year major cycles for free software? Says:

    […] Mark Shuttleworth » Blog Archive » Meta-cycles: 2-3 year major cycles for free software?. […]

  92. Kris Bloe Says:

    I’d like to know what makes an LTS release worthy of being labeled LTS. What advantage does this have to a user other then the length of time the OS will be supported?

    As much as I love new features, I think bug squashing is just as vital. Personally, I’d have the normal 6 month gap between normal releases, but when it comes to an LTS release, I’d have a 2~3 month development time between the normal and the LTS releases which is solely based on fixing bugs. As a user looking for a tough system, I’d feel happier knowing this amount of time has been spent fixing problems.

  93. trent Says:

    I like the 6 month cycles, they seem to keep things stable and regular. However every so often I think you need to make a bigger jump and then fall back to 6 month cycles to keep things from going stale, and to work in the larger changes. Maybe two 6mo, then a 1 year..?

  94. leslie Says:

    Our computers that we use for training ubuntu are all running LTS release,

    the main reason is that becoming used to Ubuntu for new users takes its time,

    for us this is an year cycle, from training, and them getting used to their own ubuntu boxes. What would it be if we train people to use ubuntu on the desktop or server and we had to change the program every time when ubuntu changes?

    One point is that a year has its own cycle with the 4 seasons, you see it in the working place, the school, university etc, so an year cycle seems to be an natural swing to follow.

    The cycle could be any time line, i think , because you could add the software at any time until the release freeze, after which the cycle would start all over.

    For example Gnome developers can use their own cycle, and release it when they are ready to do so, as they do right now, if its in the ubuntu release it cool, if not, it will be in the next release.

    It would not be difficult to create an visual time line that shows the projected releases of software and their release in ubuntu.

    Now i understand you, personally would like to see a more predictable cycle,

    but there are a lot of various open source eco systems out there, from the professional to the personal project, which also need to be taken in to consideration.

    For me personally it does not matter, actually i would like to see more priority on bug free software, that works, what ever cycle that takes.

    An other thing which comes to mind, i understand that if you still need to reverse engineer hardware to create drivers, then sure is every two year is and idea, its logical that the software developers would need that extra year to get the drivers done for new hardware.

    If ubuntu would also be sold in the shops, as it is right now, and could be more in the future, there is a point of waste to consider, Long Term Releases would create less waste… :). Mabye we could also create an special ubuntu bundle for the public library, wich they could lent out, needs to be LTS.

    So i thought i be brainstorming with you for a moment, and yes i am just an Ubuntu desktop user, keep up the good work, i am happy with the way it is right now!


  95. Luser1138 Says:

    A two-year LTS cycle, with three years support on the desktop and five on the server seems just right to me and is one of the main reasons I chose Ubuntu in the first place. I’m using 8.04 on my SOHO desktop, laptop and server. I don’t want to upgrade every six months because I don’t want to spend a couple of days working around each version’s inevitable quirks in sound/printers/codecs/wifi/X/java/flash etc more than once every two years, or learning how to configure new versions of BIND, Apache, Postfix, Dovecot etc., more than once every four years.

    On the other hand, a 2-year old desktop will have some pretty tired versions of applications, and stretching the planned 10.04 LTS to 10.10, and even that assumes Debian can keep on track, will make that worse.

    It would help if the LTS desktops could have more backports of major apps, e.g. 3.0.

  96. Brock Says:

    I agree with the “I think releasing an LTS every two years and supporting it for three is a good idea.” comment.

    The LTS overlap for migration is a nice selling point, and having a three year LTS period would be greatly appreciated. I have a hunch many who prefer the idea of two year LTS cycles are really more the six month release type, and that is served with the current six month releases.


  97. John Says:

    So this isn’t exactly responsive to your blog post, but it follows up on some of the comments and it’s been on my mind recently.

    What seems to be lacking from the current Ubuntu LTS scheme is any reason to believe that an LTS release will be of higher *quality* than any other release. Sure, it will get 3/5 years of support rather than 18 months, but that support is limited to security updates and a very few critical bugfixes. If the release has a bunch of semi-broken software in it, you can choose to live with it longer, but it isn’t going to get fixed. And given that the process that gets you to an LTS release is identical to any other release, you can expect exactly the same probability distribution of brokenness.

    What I’d like to see is for LTS releases to be a polish of the last stable release, only resyncing packages that have a bum release or, in rare cases, for a major feature enhancement. No mass resync with Debian. No upgrade to the latest and greatest GNOME just because. I’m not sure you even need 6 months to do this polish cycle–maybe 3 months is enough. What you do need is to get a standard 6-month stable release out and being tested by the great mass of users who aren’t going to touch a “beta,” and the discipline to spend time fixing what’s broken rather than going on to the next new thing.

  98. Russ Brown Says:

    How long do posts take to go though Akismet? I posted four days ago now and it’s apparently still flagged as potential spam. :(

  99. Oliver Says:

    Why not steal something similar to Windows?

    18-24 month cycles (which allow major revisions to core packages and major paradigm shifts such as PulseAudio, notifications, Python 3 or the latest major update to the environment) with shorter 6 month “service pack” updates (update to the latest minor GNOME release)? This allows for both minor revisions and major changes.

  100. Donnie Berkholz Says:

    I like “supercycle.”

  101. Bradley Says:

    I agree with Jo-Erlend Schinstad in that an LTS should be the last in a series before major changes for the reasons he stated.

    The goal for releasing a new LTS should be every two years, with slippage to 2.5 years a possibility. That’s short enough to get significant new features in a reasonable time without getting burnout from constant upgrades. (My wife complains bitterly whenever I upgrade anything on any machine she has access to, so they get LTS. I prefer the edge on my machines.)

    I would suggest that the first two six-month releases after an LTS encourage changes that significantly affect either the user experience or the system organization. The third six-month release allows only relatively minor changes, while the fourth—the target LTS—is even more strict.

    With respect to coordination with upstream, I agree that individual subsystems will have their own pace of major and minor cycles. Attempting to force a one-pace-fits-all development model onto them seems counter to the notion of a community of developers and would probably be harmful.

    A major upstream release just after the freeze for the second six-monthly release would be a worst case: the new release wouldn’t make in into any Ubuntu release for more than twelve months, or into an LTS release for three years. If that seems likely, you could include a late beta of the package, or add in a third “major change” six-monthly release and push back the LTS release by six months. You only get to use that lifeline once though.

  102. Paul Boddie Says:

    “So, what would the “best practices” of a meta-cycle be?”

    Actually being able to upgrade from one LTS release to the next, if my recent experiences with Ubuntu are anything to go by.

    I installed Dapper from an old CD, upgraded to the latest Dapper updates available, installed and ran the “special to Ubuntu” upgrade preparation program (to upgrade to Hardy) and got a cryptic error. The commentary from the community seemed to be the “usual for Ubuntu” mixture of “I stood on my head and now it works”, “the server was down – that’s what the error means” and “we couldn’t reproduce this bug because we didn’t try”.

    Maybe the door on using Dapper has closed and I shouldn’t have touched it in this day and age, and that brings me to another best practice: actually keeping repositories around for more than a day longer than is deemed necessary.

    Other best practices: decent documentation for common and obvious tasks that isn’t found only by surfing the expanding number of random Ubuntu forums and initiatives (populated by the calibre of contributors mentioned above) or by stumbling across people’s bad experiences written up in their blogs.

    In the end, I installed Debian Lenny instead of Dapper or Hardy. In my opinion, the closer the Ubuntu distributions can stick to Debian for matters of LTS and upgrade sanity, the better.

  103. Aceler Says:

    You can make 30 or even more month of the meta-cycle, if you have large backports repo. If user of some old-style distro can use all of the modern software — he will never need a major change of distro.

    For installation need, therefore, there must be some updates for installation ISO, because else user will need to update very much of the software, So, any period more the a year will be good for LTS, if you have backports up to date and a new installation ISO every 6 month.

  104. Pauwl Lunow Says:

    +1 with Paul on not having upgrades bomb.

    Although my timing is different. I’m approaching it from the large company perspective – where upgrading OS versions effectively kills other desktop-related IT projects for the year or so it takes to roll out on any scale. The beauty of having smaller updates (i.e. more frequent) is not only smaller transfers – but also that the incremental upgrades actually seem to work.

    Now that – worked into any cost model is a HUGE cost benefit, and a large part of the TCO if you spread it over 5 years.

    Being able to latch on to new offerings (HW/SW) as they become available is also essential in my mind to be able to demonstrate whilst still playing ‘catch-up’ with other OS’s in use in corporate environments.

    So the summary: Stick with 6 months. IF you go for a longer period, then it’s ESSENTIAL to provide some form of rolling interim updates for those willing to spend time testing releases before giving them to normal users.

  105. Karl Says:

    It looks like the KDE folks learned a lesson(1) about communication from the very raw release of KDE 4.0. The main issue here is that we denote releases with a number, but that number means different things to end users than it does to developers.

    KDE 4.0 was a developer release, but 4.2 was for end users. Maybe on the next go-around 5.3 will be the end user release. If projects rely on users reading the fine print to know when to jump aboard, there will be disappointed users(2).

    Because open source is being used by more non-technical people (and we are talking about millions of people here), there should be a plan for dealing with this confusion. It would be fantastic if there were a consistent way of denoting developer releases across all projects to make sure the end users know when they can expect stable software.

    Doesn’t the Enlightenment desktop use ‘DR’ as part of the version number to let everyone know this is a ‘Developer Release’? It would have been helpful if every post about KDE 4.0 had used the term “KDE DR4”.


  106. Meta-cycles: 2-3 year major cycles for free software? (Here Be Dragons) | Says:

    […] well known that Mark Shuttleworth is a proponent of six-month development cycles. However, in this blog post he considers the larger changes which cannot be done in six months. “Six-month cycles are […]

  107. Alan Bell Says:

    I totally get the point of having major releases like the KDE4 where there is a big architectural feature that goes in and might break stuff, but it is worth it. I don’t get the point of planning them every x years on a regular basis. LTS can be planned in advance, and a major potentially breaking change would not be in an LTS release, but I think they should be planned on an ad-hoc basis depending on what major feature is going in, and when it is likely to be ready.

  108. Sergei V. Fedosoff Says:

    I think that version hopping every 6 months is generally not so good idea, 8-9 months surely be better, we need stable software and solid distro. Ubuntu is already very solid system, with a nice selection of software, but when new release pops up it tend to have some bugs, most of which squashed (usually) in first month after release, I personally do not like to change major version of my ubuntu systems immediatly after immediately after fresh release hits the mirrors, I prefer to wait at least 3 months and after that period, when new version becomes mature enough I use it.

    LTS. Here things are changing, another pupose, different approach.
    If you’re deploy server (corporate file server, web server, home gateway) you plan to use it to it’s end of lifecycle (when hardware dies) on a modern 1 unit servers (like those fancy hp proliants dl-360 or sun sunfire x2200/x2250) it can be 3-4 years, but on 2 unit servers it can be as long as 6+ years (the same for a tower case servers, or workstations/desktops that acting as servers), so support with secutity updates for those machines should be 6 years or even more – 7 years. It sounds terrible because support of outdated programs as hard as develop a new ones (and backports are sometimes are smart move in that case), but this long support programme will make consumers trust you and rely on your software in a serious tasks.
    If you deploy a workstation – you don’t want to reinstall software (operating environment) for a long perid of time, generally it is about 4 years, than workstation hardware dies. So support here required for 4 years.

    So what about release cycles of LTS? I think that for desktops it is good to release new LTS every 18-24 months (depending of software state: Environment/Office suite/etc). For servers release cycle should be every 30-36 months (depending of state of Apache/Oracle/PHP/MySQL/PosgreSQL/Python/RoR/Perl).

    Desktop releases should be twice often than server. It will be good for OEM, for software companies (that makes 3-rd party software) and for wide range of customers (from corporate to home users).

    Oh, and one more thing – there should be one more form of release – thumb drive image file will be a good addition to a standard bunch of iso files on mirrors and torrent trackers.

  109. Simranjit Says:

    Well Mark i first saw this article on planet ubuntu and it is good brain storming. Though i write no code ive been using ubuntu for the last 2 years and ive been studying its components in great detail.The case of the different philosophies or shall i say approaches adopted by GNOME and KDE communities is a very interesting one. Earlier on KDE3 was just different from GNOME it was not better then it and when you got the smaller piece of the pie that KDE3 had then GNOME just being different is not good enough you have to be better. This is what the KDE team could foresee. As a Desktop Env. they focused on the visual aspect and the ease of use and took a revolutionary step to start from scratch and make KDE4 which was not only different but also better then GNOME (and KDE3 itself) as far as looks and “simplicity” go. Though KDE4.0 was buggy and beta-ish looking KDE 4.1 and then KDE 4.2 became pretty stable and all the criticism for KDE4.0 now the KDE people r getting all the applause KDE 4.2. and in all this what the KDE team was able to prove was the both the “power” and the “need” for metacycles or what i call “long term super releases”.

    So after reading ur article and ur 2-3 year meta-cycles this is what i purpose as to what the approach to meta-cycling should be

    0 month release “1.0”
    2nd month release 1.0.1 (only bug-fixes no new features)
    4th month release 1.0.2 (only bug-fixes no new features)
    6th month release “1.1” (newer release with new features)
    8th month release 1.1.1
    10th month release 1.1.2
    12th month release “1.2”
    14th month release 1.2.1
    16th month release 1.2.2
    18th month release “1.3”

    now in the “18th month” start getting for new ideas for the 2.0 release by starting a “brainstorming” forum dedicating a mailing list and IRC channels and then by scheduling a physical meeting/conference for finalizing the new “ideas” in the “22nd month” and after this meeting get working on the “2.0” release

    meanwhile in
    20th month release 1.3.1
    22nd month release 1.3.2
    24th month release “1.4”
    now in the
    25th month release “2.0 alpha 0” (alpha = internal/developer/community release)
    27th month release 2.0 alpha 1 and 1.4.1
    29th month release 2.0 alpha 2
    30th month release 2.0 alpha 3 and 1.4.2
    31st month release 2.0 alpha 4
    32nd month release 2.0 alpha 5
    33rd month release 2.0 beta 1 (beta = public release)
    34th month release 2.0 beta 2
    35th month release 2.0 beta 3
    35th month 2nd week 2.0 rc 1 and if needed a rc2/3 at an interval of 5 days
    36th month release “2.0” the “meta/super release” and 1.4.3
    …….42nd month 1.4.4

    now this may look a very rigid schedule i propose it only as a prototype whcich can be flexed and improvised .

    the good thing in this release cycle is

    1 for the end user – (a) while developers are working on the new super/meta release they keep on getting bug fixes for their current release ie. 1.4.1/2 so their current package/program is pretty much stable and (b) even after the release of the new meta/super release they can still stick with the current generation of releases ie. 1.4.3/4 even after 6 month of the new series. With this they can make an easy switch especially when the package is involved in a core task of the end user.

    2 for the developers (a) firstly they get 4 months to discuss and finalize whats going to be in the new super/meta release so that a good amount of new ideas come in and all disputes are solved before they get physically working on the new project (b) they get a full year to work physically on the new release and that is along time for preparing a stable and sturdy program
    (c) while working for the new super/meta release they only have to do bug fixes and add no features in the current release and when the new super/meta release nears down they only have to do it once after 6 months.

    well thats all i could suggest ….. hope to hear back from you on this

  110. » [espresso] Aaron Seigo sui meta-cicli auspicati da Shuttleworth Says:

    […] read Mark Shuttleworth’s blog entry about meta-cycles this evening and was taken back in my mind to an entry I wrote in September of 2007 about […]

  111. Nathaniel Says:

    Mark, I appreciate your work in the free software community, Ubuntu, etc. I know you would like to do a lot, but one area you could really do a lot without a whole lot of work is to commit more resources to making Ubuntu free. You had a great idea with Gobuntu, but because of various reasons it’s not moving forward. One thing that you might consider is finding a way to contribute more to making a free alternative to the flash player, and making it known that having one is really important. I think that if you were to put some weight behind that there would be a LOT of appreciative people. I know this post isn’t about what I wrote, but this is a handy way to get my plug in.

  112. Xman Says:

    results = ideas x ( time / k )
    but since time flows anyway ( and unfortunately only in one direction ) we have usually better results controlling the ideas. 3 years is a reasonable time frame for a “step” but is “to do what” that I see more important.
    We know that X world ( unlike W world ) is “baazar like” but we need to find a “catalyst” that drive the progress. The “catalyst” need to be at very high level. Hardware, kernel, dev-tools, OS, X, DEs, user apps are under control of many big players and Mobile, Desktop, Server users and professionals have different goals and requirements.
    Answers to questions have driven the mankind.
    What sees a desktop user in front of a 3 NB with 9.04, Mac OSX, Vista?
    What needs and IT professional that need to manage 300 desktops?
    How to save time/energy?
    The catalyst could be a “place” where high level questions receive high level answers.

  113. Barbie Says:

    I believe it takes a lifetime to produce a “Masterpiece”. There is no need to rush these things Mark. Enjoy the journey Sweetheart!

  114. Serge Kurilovich Says:

    My opinion is that 1 year cycle for desktop version is a reasonable choice. I am not sure about server or LTS version becuse I do not have such experience.

  115. Martin Says:


    As a person working in a large non-linux corporation I thought some input from that perspective could be useful. I personally will be migrating my home setup to Ubuntu in the next couple of months. I have already migrated the in-laws and they are very happy with a non-Windows set up. They are old people and are so relieved their set up is more secure and they don’t have to worry about viruses. This really is a big deal for them. Any sign of a virus on their previous (Windows) machine was a cause for panic and anxiety.

    Short term releases for bug fixing should be called something like “Service Pack”. It is not a new version as such in the historical sense.
    Short term releases that put new functionality or features into the OS should be called an “Update” or something similar.
    Long term releases can be called anything to indicate it is a long term stable release that can be used for years. Grand cycle is OK but LTS is already established to indicate that it will be supported over a period of years as opposed to months.

    Talking about the length of upgrade cycles I see you’re taking into account many things except one. The missing piece that I think should at least be thought about is the hardware replacement cycle in big corporations. Generally there is a three year replacement cycle for equipment and that is usually when IT and the users expect to move to the next version of the OS. MS messed this up with the massive wait for Vista but traditionally thats how it’s been. So from a big corp perspective if you buy hardware for three years you want the corresponding software to have the same shelf life, usually because it’s all bundled in with the cost. By the time your hardware is ready for replacing your software is nearly worn out too! :-)

    I am also concerned about the talk regarding breaking new big releases and then watching them settle down over a period of months. This is not what big corporations need or want. My understanding so far of the small fast iterative releases and then the long term release with support is to bring big corporations into the Ubuntu sphere. This has already had good results but if you now want to break big releases I think that would be problematic. By all means break the small iterative releases, this brings a lot to the party as there is testing, fixing and the OS moves forward as a result of it. But big breaks don’t work for big corporates. If that is the case then they will simply wait for the next release they regard as stable or maybe go somewhere else where they can find the stability they need. This will have a negative impact on their involvement either as consumers or contributors.

    Apart from that, thanks for the amazing work you guys are doing. It is appreciated probably more than you know.

    Regards, Martin.

  116. David Says:

    I’m in the camp of the 2 year cycle, also. If one looks at Intel and the processors they develop, they usually have a new platform (size reduction) every couple of years and in between they have an “enhancement” inside the platform (speed boost, more internal memory, better power consumption, etc…).

    As a community driven effort, I imagine that we could do the same kind of stuff. Example: Odd years – Major, groundbreaking, platform releases; Even Years: Improvements on those platforms. This would allow for example that some projects could adopt a 4 year cycle if for example they couldn’t do it in 2 (Thinking about KDE!)

  117. Anon Says:

    Time-based releases are effectively enjoyable by all kind of users, and have been more and more common in open source projects. What OSS should be granted is not perfect accuracy, as what a new distro ultimately should try to deliver on new releases is giving the user the ‘newest’ but usable and integrated code of the upstream project, and could involve last minute breakages.

    In fact time-based releases are so the norm that the “industry” will not widely adopt a new release of an OS until its first or second update / patch / service pack. Users were getting used to badly written apps released with a dead line. Hopefully time-based release will not affect the quality of OSS code :)

    6 months is an ideal release cycle in my opinion, however answering how a certain release should be supported for is very hard to answer. If you don’t drop releases, your engineering and support costs will be prohibitive, if you do drop too early, long term projects will not consider it.

  118. Marcio Says:

    For big companies, 3 years is better. The place I’m working now changed from fedora to ubuntu because it was impossible to maintain fedora updated on all machines. But 2 years may be good enough too. Two and a half looks weird for me too.
    I think LTS at version X.0 is not a good idea. Many bugs will appear and every time somebody install a “clean” LTS, it will have to update everything and some bugs may make it a little hard, especially if the LTS updated everything at the same time (kernel, gcc, X, gnome, ..). Version X.2 or something seams like a better idea.

    ps. Its great to see you asking and talking with the community. That’s what makes ubuntu so great!

  119. Luke Says:

    Can bold releases be planned to immediately following every LTS release?

    regular -> regular -> lts -> bold -> regular -> regular -> lts -> bold -> …

    It could be a nice compromise with the community, having a bleeding edge/whole stack changing release every two years (latest kernel, x, gnome etc) and then two years of ironing out before the next LTS release. For the less daring users there would be a year between a LTS release and the next stable regular release, which would also bring a whole bunch of new features.

  120. alzibub Says:

    How about a fork-and-fold approach: exciting projects that may not complete
    within the 6 month window could be worked on in separate repos that are forked
    from the main repo. Developers, and users interested in playing with the
    experimental feature, could use the forked repo. Let them work through
    the bugs, and keep the forked repo relatively up to date, until the feature
    stabilises. At this point the feature is ready to be folded into a release of
    the main repo, and the forked repo can be retired.

    This is roughly what happens now with kernel development using git. Developers
    “clone” repos, make “branches”, and “pull” upstream changes into their branch
    while they are working on their new feature to keep it up to date. When the
    feature is ready, the branch is “merged” into the main repo. This model works
    very well, but it’s still going to be a lot of work to port this development
    model to a project as big as a linux distro!

    This system would give Ubuntu the best of both worlds: regular releases that
    keep it compatible with the latest hardware, and keep users confident that the
    distro is not stagnating; but also space for enthusiastic and able developers
    to experiment with new ideas, so that they don’t need to look elsewhere for
    their kicks.

    BTW, thanks for all your support of OSS. The world’s a better place for it!

  121. anzan Says:

    So, Ubuntu 9.04 is now released. Congratulations to Mark and all.

    But it’s shipping with a big bug in Brasero ( ) that also breaks Totem.

    A fix is available but was not included due to the freeze.

    Do dates really matter that much?

  122. David Says:

    The post mentions the biggest and most difficult question about meta-cycles: where should they come in relation to the smaller cycles?

    A big part of the reason for having meta-cycles in the first place is to show off the bigger, flashier changes that one might not notice as much if they one upgrades through the various the incremental releases. This suggests that the meta-releases should show off the newest of the new, especially in the desktop environment, and that these meta-releases should serve as the flashy public face of the project.

    OTOH, the other attractive aspect of meta-releases is stability (and in the case of Ubuntu in particular), long term support. This suggests that the meta-releases should be the most solid and stable (risk-averse) releases. Thus the meta-releases are attractive for two conflicting reasons.

    Follow up idea:
    The post also made mention of KDE 4.0, which many in the community regarded as a disaster. While I want to avoid a discussion of the merits of releasing it with Ubuntu 8.04 and 8.10, I do submit that less technically minded users of Kubuntu who upgraded to those versions had no way of knowing that they were moving to a not-quite-fully-functional version of their OS. At the time, I was advising people to stick with 8.04 + KDE 3.5 the same way I would advise people not to try a beta version.

    I only bring this up to ask about the bar we are setting for regular releases. The more emphasis we place on stability in the meta-releases, the less we will tend to emphasize it in the 6-month versions.

  123. Derick Says:


    The primary problem with Ubuntu’s current release cycle is that applications are locked to each release. I’ve been using Ubuntu for almost 4 years now, and I often find myself going ahead and upgrading to alpha and beta releases just so I can get the latest versions of all my apps.

    I truely believe it would be in everyone’s best interest if you could decouple the actual OS components of Ubuntu into fixed release cycles, but let the individual apps run as a rolling release (constantly/rapidly updating). Obviously, I want the kernel, gcc, python, gnome, gtk, alsa…things like this to stay fixed to one major.minor version, but there’s no conceivable reason I would need to stay with the same version of Inkscape or VLC. One way to make such a transition easier would be to find a way to make apt play nicely with multiple versions of the same program installed. Another issue is apps like Firefox and Open Office which are officially supported and installed by default. It may seem much less appealing to do rolling updates of such apps, but I think the solution is simple….move any software that is not absolutely necessary into Universe/Multiverse. However, this would now mean that Canonical would be doing official support for packages in the *verses. This may make things seemingly more confusing at first, but it would serve your users better I feel.

    At work I’ve been running off 8.04 LTS, and I really don’t want to have to upgrade/reinstall until the next LTS release, but my apps are getting so long in the tooth that I may have to suck it up and use 9.04, even though it probably won’t be quite as stable/polished as an LTS, and obviously for my work machines they absolutely have to work. This is the conundrum the current release cycle with all OS components and apps locked creates.

    I could go on all day about this topic, but to sum up….if everything in Main/Restricted were released every 2 years as an LTS, while Universe/Multiverse were allowed to update freely as rolling releases I and, probably many other people would be much happier with our Ubuntu end user experiences. Thanks

  124. Leif Says:

    Yearly or bi-yearly cycles make more sense in the organisation i am in. There are periods of time (historically summer) that are quieter and give a chance for hardware and software upgrades to happen.

  125. David Says:

    Are there patterns in nature that provide an example? Many plants in the desert flower when it rains. Tree rings expand every year, but more in warm, wet years. Nature appears to be adaptive, and rarely keeps to a rigid cycle. Planetary cycles are more regular, with many upstream overlay cycles and confluences.

  126. gp Says:

    why meta packages ……….why not different type of ubuntu subscriptions (system updated directly from regular updates ……………no need to updrade
    1)Countinius subscription : get feature as and when its released (here user is system Alaways updated INCREMENTALLY to current release
    2) Meta Subsription : Long term upgrades

  127. Primefalcon Says:

    I have to say that was a great read…. I personally like the release cycle of Uuntu how it is, from what I am seeing there is a huge amount of innovations in Ubuntu

    The upcoming Koala sounds sounds like it’ll revolutionise a lot about how servers utilise power, I can see a lot of other distributions following that method too….

    I Also want to say this, Thank you Mark for pulling everyone that you did together and creating Ubuntu, it really has opened my eyes to Linux and the wider software world as a whole. Keep up the great work….

  128. UWP Says:

    I’ve seen long-time releases my whole life. RedHat, SuSE and others have “Enterprise” distributions which bring very old software with them. And sometimes an even longer cycle: Debian stable. In my opinion the long term stuff doesn’t make anything better. I’d say, it’s quite the opposite. Normally I’m not friendly with “versions”. Seen from user side I don’t need them really. I’m doing updates once a week and the whole system is moving on slowly. Yesterday I made the big change: jumping from an uptodate 8.10 to 9.04. On a laptop. It broke koffice. Just this small step from the newest 8.10 to 9.04. If the jump would have been bigger it might break even more things. Software itself is aging and when you’re not doing constant updates you will get lost in a state where the new software cannot simply replace the old one, because the dependencies have changed their names, their purposes or sometimes even disappear or you might need even more packages which break installed software etc. I’ve seen this in the past very often at Debian systems. Seldom a jump from stable to the new stable version worked out of the box. It got quite better when Debian got a smaller timeslice between major updates. In fact, I’d prefer even less than half a year for major updates. But I can live with it. But please don’t change it to more long term.

    Anyway: the new 9.04 version looks quite good (I don’t really care about broken koffice, but it was a good example for my reasons :))), the Ubuntu team really did a good job! Thank you for this nice piece of software!



  129. firebird Says:

    dear mr. shuttleworth!

    i am really sorry to have to say this, but as criticism was required i feel urged to give some:
    i cannot quite understand why anybody would like to stick to these circles by brute force instead of simply publishing a distribution when it is MATURE.

    i use ubuntu not only for myself but in a productive environment and i chose to use it over debian for actuality reasons, manly speaking of availability of drivers.

    before gutsy gibbon i was really convinced of ubuntu but ever since these half-yearly releases i am experiencing problems over problems, in worst cases crashes during dist upgrades rendering the system completely unusable, meaning broken in way that i couldnt fix it anymore even after trying for several days.

    to speak it out clearly: i have migrated like 30 machines of completely different brands from hardy to intrepid and NOT ONE SINGLE ONE was working cleanly after that!!!
    (mainly network-manager and graphics drivers problems)

    in other articles you speak of attrackting a bigger user base through eyecandy n’stuff, but personally i have to say that i prefer a WORKING system over a nicely looking one.
    surely you will take into consideration that your userbase will also not grow if your distro is known to be a hihgly buggy one and that is exactly what i have been learning lately.
    not only from my own experiences but also from what i see from fellow admin colleques who are already switching to fedora for the above reasons.

    after all one gains the impression that lots of stuff isn’t even being tested before being put into the release. a short example to clarify what i am talking about:
    i set up two servers with ubuntu and xen. after implementing the xen-guests (ie. domU) with debootstrap i had a non working tty1 as in /etc/event.d/tty1 all of a sudden there was an xvcd0 entry instead of tty1.
    this had the effect that after booting the server when all services had started no login prompt showed up.
    further the script /etc/xen/xend-config.sxp hat a duplicate entry of the keyword “cut” rendering the whole xen service unstartable.
    nobody can tell me that anybody ever tested if this actually works before it went into the release because they would have clearly seen on the spot that it doesn’t.

    finally i want to say that i find it really a pitty that Ubuntu’s quality has decreased in this substantial way. if this goes on like this i will sooner or later also swap the distro…

    thank you very much though, for giving the opportunity to give feedback i really appreciate that!
    yours, firebug

  130. A. Macchi Says:

    Dear Mark,
    These questions and issues that you raise are indeed very important and relevant. They are classic dilemmas and I believe that open source is sometimes paradoxically weak on coordinating efforts, despite that fact that we have many many common goals. Please allow some fluffy discussion on classic dilemmas, before I go back to best practices in software:

    The first classic dilemma is long term focus versus short term focus. The solution is to focus on both fronts, as Ubuntu already does by having a combination of frequent short term releases alternated with LTS-releases.

    The other similar dilemma is of timed or rhythmic “minor” releases versus “big bold moves”. Again there is no win-win single solution for the dilemma, but to remember that cadence creates a good discipline for a community, and may improve our productivity. The opposite extreme, of only having Big bold moves is risky since the goals may get too far away in our minds. Details get postponed in long projects and the main picture will change before final delivery.
    Again, I believe that a regular pace of minor releases in 6 months is powerful, when combined with concrete goals to deliver a few valuable major features.

    The third dilemma is individual (efforts, projects or distros) versus collective efforts. Shall we run our own race to be sure we can get there? Or shall we wait for the group to join us and coordinate our efforts? The solution again is to find a good balance between the two extremes. An yes, here Ubuntu may also have a good answer, being strong in its own for regular releases, but at the same time changing the landscape in open source, since many projects can count on Ubuntu! Hopefully many projects may see the advantage of coordinating their efforts around Ubuntu releases.

    Sorry, by adding some management fluff to your blog just in order to tell you that:
    Yes, Ubuntu has already many of the answers and we can hope that many open source projects will adopt a similar successful structure. And even better: we can hope that many open source projects may start to look around and think on the advantages of coordinating efforts in common minor releases.

    PS: In my world as manager in industry I cannot wait too much before adopting a solution. Two years before release is not feasible. But a maximum of 18 months can be acceptable sometimes for business needs. Any long project must be divided into manageable parts.
    Along the years I have witnessed many technical projects that fail because they could not deliver graspable results regularly. It is often better to deliver a few stable and valuable features at a time. Large increments are expensive and risky. (By the way, the marketing guys may later find bold descriptions for the accumulated minor releases).
    But in essence we build our own future one stone at a time and one new level at a time. Yours Sincerely /A.Macchi

  131. phiphi Says:

    My thoughts are:
    An LTS version is for Businesses, so it should be the most stable of a Meta-circle.

    But A Major-circle could give points for major changements.

    So I thought, that it would be nice, for a major/meta-circle-releasedate or whatever, to have TWO versions released:

    – A LTS-Version that sums up the improvements of the previous circle and has as few bugs as possible, but with less new features

    – And a Version in which new (major, less stable) features are introduced. This would be built upon the “bug-free” LTS Version, but continue with the development of features.

    The minor Releases in between should refine the new major features and introduce smaller improvements. (as it is now)

    Like that, businesses have provided their needs and developers and average-people have the new features at a Major-Circle-releasepoint.

    The new features are good for Marketing and the press…

    (I think 6 months minor and 2 years major-circle is best)

  132. tchalvak Says:

    Release syncing:
    Sync up regular releases with -everyone- we can get, especially (and perhaps most importantly) Debian. Synced releases will help increase energy going in to development.
    But do NOT sync up LTS releases in the same way, make them a Special case that happens -after- a synced regular release has had time to stabilize for a few months. So standard release might be 10.4, but the LTS based on it would come two months after, so 10.6, for example.

    Let LTS release = a speed release:
    In a sentence: when it comes to LTS, the work going into it should be focused primarily on speed/performance/stability, to the exclusion of new app features.
    Can you imagine the blistering results we could have if every year and a half, a few months of time were devoted exclusively to speeding up and stabilizing ubuntu?
    So from the release before a LTS to the LTS, the focus could be speed/stability/performance over features, and after the LTS, incorporating new features would start up again.

    6-month breakages are too frequent to keep productive:
    Truthfully, breakages during upgrade in Ubuntu has made me question whether the very concept of a “release” is beneficial. I want my security/memory updates weekly, my application updates cherry-pickable when they’re made available, and my whole-os-upgrading once a year or perhaps once a LTS. Where the ubuntu release system seems to fall short is in allowing me to keep up-to-date with quick-moving application changes as I want them.

    That said, I know that point releases are what almost all OSes do, and I see some nice developer energy coming from the six month release schedule, so I think that synchronizing distro releases will only increase the speed of linux development. But for users it seems to me that the ideal to work towards is to have security fixes available immediately, application updates available not long after their creators provide them in their repository, and operating system upgrades (paradigm shifts and settings changes) only once in a while, only every year or two. Maybe that’s not easy to do while maintaining universe repositories and .deb binary package creation, but perhaps just easier repository finding and upkeep would solve that problem.

  133. Shea Kauffman Says:

    I’ve been thinking about this same thing.
    It occurs to me that there are four levels:
    Incrementals – Updates, occuring daily
    Minor Versions – 6 month cycle, bug fixes, optimizations, new features – equivalent to a windows service pack.
    Major Versions – 1-3 year cycle, Radically altered user experience, equivalent to a new windows OS (i.e. 2000 -> XP)
    Radical Versions – 3-6 year cycle, Alterations on a platform level, kde3->kde4, windows 98 -> windows XP

    It’s not just OSS that seems to stick to these patterns. Photoshop tends to have a 1-3 year release schedule. With the larger cycle 1->4 (6 years), and 4->CS 6 years, I’d guess that the CS line is due for a change. Maybe it’ll be supporting Linux.

    P.S. Good job on 9.04

  134. MikeMLP Says:

    gp – you’re confusing meta packages with meta release cycles. Right now, you do get continuous support with non-LTS releases. Governments and businesses naturally prefer LTS releases because they do not want everything to change all the time -it becomes a pain to support a moving target. What mark is asking is how to coordinate development efforts so that one can make the most of longer-cycle releases.

  135. kikl Says:

    Dear Mr Shuttelworth,

    I am very pleased with the new ubuntu release 9.4. The product just seems very polished – your designers appear to be doing a lot of good work. The new notifications are unobtrusive. The computer is a lot more responsive. You are definitely going into the right direction. Unfortunately, I got a new problem with the printer driver, which would only send default prints (US letter), which were refused by the printer, since A4 was loaded. So I filed a bug report yesterday. The community helped really fast. I got a fix for the problem today! No that’s fast support.

    Just Keep up the great work!



    PS: The beautiful netbook release is working just fine on my LG x110!

  136. Zelrik Says:

    Hi Mark,

    I actually have a question for you. I am not sure if you can answer it here. How do you consider other distributions that are actually ‘downstream’ of you, for instance Linux Mint which is Ubuntu-based ? Do you work some with them? Do like them? Not? Indifferent? Just give me your opinion on it ^^ .

    I am trying Linux Mint right now and I like it a lot so far. :)

  137. Davide Del Vento Says:

    my (perfectly polite and constructive) comment was marked as spam by Akismet :-(
    If I understand correctly the way Akismet works, you should approve it by 2 weeks (more than 1 is already gone), otherwise it will be permanently deleted. Please do so.

  138. Yavir Says:

    As for the name, I think “bold move” is great. It’s less meta than any “-cycle”, “-circle”, etc.

  139. Jose Luis Says:

    I see two different problems here: one of coordinating release of new functionalities, and one of coordinating support terms.
    On the first one, I think it is not realistic to expect than major components of such a diverse environment as Linux can be synchronized. I think the beauty of the “six months release cycle” in Ubuntu is precisely that it inverts the terms for the distribution: instead of knowing what but not when (which is what you face when you want to do a big change like KDE 4 or Python 3), you know when but not what (you just know that “whatever is ready by then, I’ll have it integrated”). While “demand” pulls mostly from the distributions, “offer” will pushes from the downstream projects, and what the “six months release cycle” does is to fill that gap, and put some order and predictability. IMHO, Ubuntu release cycle is not only good, but it is one of its biggest success factors. Long term release and short term releases are not very different from this point of view.
    The second issue, coordinating support terms, is trickier, and I guess is the real issue from the point of view of a distribution. I think the coordination with downstream projects (and with other distributions, specially Debian) should focus on this, even when many of those projects do not have any formal “support term”. Again, demand (usage) is mostly determined by the distributions life cycle, and that should in turn drive the downstream support, either in a proactive way, through release coordination, or in a reactive way.

  140. anzan Says:

    …and suspend/resume is broken on a ThinkPad R40 running Jaunty Ubuntu/Xubuntu and this seems fairly common on the forums. Which is fine as I’m just testing the release on a nonessential box (I’ll file a bug report).

    It is pretty though even with the brown.

  141. Charles W. Downing Says:

    I am one of the newbies some are worrying about. Although I have been dabbling with Linux since late in the last century, only last summer did I completely drop Winblows. I hope you continue the practice of LTS. Somehow, the transition from Gutsy to Hardy was easy for me. However, I have yet to complete the transition to Jaunty because your server was overloaded on announcement day.

    Keep up the good work, Ubuntu is really great!

  142. Iniyan Says:


    Personally, I vote for a flexible release schedule for an LTS – by the way, as far as the naming goes, someone’s suggestion of ‘Milestone Release/Edition’ above sounds a lot better! – and sticking to a six-month release schedule for introducing incremental changes in stability. The release of an LTS can vary from anywhere between 1.5 years to 3 years depending upon resonance with major changes in other projects. For the next LTS, I stand with you for moving it up to 10.10 or with the suggestion of zelrik above (which sounds even better), to move it to 11.04 – make big changes in 10.10 and release 11.04 rock solid!

  143. Frank Says:

    Hi Mark,

    very interesting and important post.

    I remember that you once wrote or spoke about the Ubuntu releases this way:

    * LTS is a very stable release which can be used in companies or private where stability is high priority
    * LTS+1 is a release for the developers, where they can “play” and experience and integrate new things (and even break things). Some users will update to this release but some will stick with LTS because of stability.
    * LTS+2 will ‘stabilize’ the LTS+1 release.
    * LTS closes the circle, the new ideas from the developers are not stable and can be used in production.

    Please correct me if I understood wrong, but I really liked this release behavior because it’s predictable and everyone gets what he needs: The geeks and developers have their brand new release to experience and play, the average user has it’s releases with actual software, the companies and non-experienced users have their stable release without having to fear updates for about 1,5 years.

    The bad thing about is that it doesn’t seem to work that well lately: LTS release is not as stable and bug-free as it should be, the LTS+1 release does not contain many new things and ideas but more bug-fixes that missed LTS. Uh.

    Is that why you are thinking about changing this release process? I would rather like to see you give it another try, it’s one of the things that make me use and spread Ubuntu! :-)


  144. Abdallah Says:

    Hi Mark,

    For minor changes, I really like ubuntu for their 6 months cycle. It is predictable, it’s close by, and it brings some of what I want. I do have to say that I did not update from 7.10 to 8.04, but waited till 8.10, although I have moved to 9.04 already. but that is me. So I think this cycle should still be around.

    For major updates/changes. I think anything more than two years for major changes is way tooooo long for the following reasons:
    1. People involved loss interest and want to spend their time on something more interesting or gets involved in other activities.
    2. The project itself losses its momentum and lose direction.
    3. Committing time is difficult the longer it gets
    3. New ideas and technology are coming out these days faster than normal, and waiting three years is just too long.

    my choice would be 18-20 months, but 24 months is acceptable.

  145. Ole Eskildsen Says:

    Eh, well, Mark, excuse me, but what happened to my previous comment?

    It was NOT a spam!
    It contained NO nasty comments!

    It only contained my constructive suggestions in reply to your request for suggestions and comments!

    Now I’m left wondering whether there is any point at all in submitting comments and suggestions.



  146. Ole Eskildsen Says:


    Could someone please tell me why my comment above is being labelled SPAM???

    Or perhaps I don’t know what spam is, could someone please enlighten me!

    I thought that spam is when somebody unsolicited tries to sell you Viagra or fake Rolex watches or other similar sleazy products?

    If that is not the case and SPAM is what I have submitted above, then I stand corrected and apologize!



  147. coskunlar vinc Says:

    I think that putting the most emphasis on LTS or meta-releases and putting forth intermediate releases, which are generally more like “Service Pack” releases of bugfixes, as, well, intermediate releases which are mainly bugfixes will present a quality of stability and dependability to users.

  148. nauhgt101 Says:

    DEFINITELY long term support on the previous version. KDE4 landing AFTER a kubuntu LTS was definitely a good thing – I’ve made sure the friends and collegues computers haven’t been upgraded since, because kde4.0 and 4.1 was so painful to use.

    I would say, LTS could also come at a point where all the punters have stopped complaining about the new version – ie. probably kde 4.3, for me.

  149. Dante Says:

    Hi, Mi name is Dante and I am a Liberal Arts student, my focus is Mediterranean Archaeology and History.
    Therefore, you can call me the perfect “average user”, who doesn’t know much about computers, is not expert in how they work, but has discovered the huge benefits, convenience, and better quality, of open-source software. I started using Ubuntu with version 7.04, and never stopped since then. Now it has become my main OS, and I converted to Ubuntu also all my family’s machines (five of them). No one of is a computer guru, and we all are perfectly happy Linux users. I use Virtual Box to run Win XP and the only software I could’t leave behind (EndNote, Site Recorder 4, and Adobe Acrobat).

    I’ll tell you a few things about my own experience with releases cycles. I found huge improvements since version 7.04. Version 7.10 (64-bits) didn’t work well on my machine at the time (an HP Pavilion dv9000), but all the issues I had were fixes, step by step, by version 8.04 (the wireless worked out of the box!), and 8.10 (my 3G modem suddenly was ok!). I haven’t upgraded to 9.04 yet, just because 8.10 is absolutely perfect. My pc has never been in better shape.

    Now: for me, knowing that every 6 months Ubuntu was becoming better and better, seeing my hardware problems fixed at predictable intervals, kept me from switching back to the Windows world in case of problems. I knew I had to hold on and wait a few more months to get a better product available. Seeing all the issues solved, release after release, made a huge difference. If I had to wait indefinitely… probably I wouldn’t be writing you.

    It is impressive how much good work you have done. I truly love Ubuntu. I think you had to give constant releases at a fast pace to bridge the usability gap with Windows… but now, the work is pretty much done. Auto-detection of the hardware is even better. I would keep the fast release cycle going for the next couple of years, and then it would probably make it sense to slow it down to every 12 months? Just ideas.

    Thanks for giving us such a great product.

    Keep up with the good work!



  150. ikonia Says:

    The LTS cycle will providing an excellent support model is one of the biggest negative factors I get from businesses from SME to multi-national blue chip not picking up ubuntu as a desktop and server platform.

    The lack of bug fix and package maintainence (perception – not fact) is a big turn of and concern, the 6.06 dell server hardware issue not being fixed out of the box untill 6.06.2 was a big turn off to a lot of business pickup that I discussed with (just as an example).

    the LTS product and support cycles is fantastic, but more effort needs to be shown to be going into maintaining it and features from the later non-lts releases being back ported as “main” rather than unsupported backports needs to happen. I’m not talking about bleeding edge packages, but moving of bug fixes for say php 5.X to 5.X.+1 getting back ported into a supported situation (php is just an easy example)

    I understand how this can be more trouble on the desktop (the firefox version issue on the desktop of 8.04 is a good example of this also) but it is important for a business to feel they will not have to upgrade away from LTS to get feature improvments or bug fixes, and that their bug fixes and package updates will happen in main rather than unsupported backports repos

    Maybe this is also a good time to float the idea of splitting the server and desktop versions also – again, the perception I get fed back is that once LTS is out the door – the focus is on the next non-lts releases and that LTS actually dies, one of the limiting factors for this I believe is the desktop, splitting the server and desktop product will open doors in a lot of ways.

    I’d love to discuss this more

  151. Spacious Says:

    Hey Mark, this has little to do with your post, but has something to do with SPACE, although it is not obvious by the “spiritual” coating… Since you have declared yourself an astronaut (:), and seem to have interest in space matters, I was wondering if you have read the book “New Earth” and what your thoughts are?

  152. Victor J Kinzer Says:

    I have always been amazed at how people are able to argue the short vs. long release cycle. If you look at any major software there are always both. Firefox, has point .0x releases to fix bugs, .X releases to introduce significant features without a total structure overhaul, and X.0 releases to do a major overhaul and introduce major innovation to the software.

    I think the part of this cycle that is currently missing from the discussion in open source, at least how it is portrayed here is the issue of feature maturity. For a project like KDE or Gnome they can do a major break with a X.0 release and it’s fine as long as the older infrastructure is supported for a while until all the bugs associated with a big break are worked out.

    Windows (I know shudder) gives a perfect example of this cycle. Since Windows became a major installation in business the first incarnations of major releases do not get deployed. Everyone “Waits for the First Service Pack”. These service packs often introduce new features that are truly stable, but don’t make any major changes. In terms of a finished product like a distribution we need not only the quick releases that could create problems, and don’t necessarily have major vision because of their speed, and the big releases that push things forward, but also releases that “stabilize” the LTS releases. Sometimes it may even be appropriate to introduce some very utility new features such as high priority driver support in these releases.

    The other option would be to push more experimentation in non LTS releases and then LTS releases do not introduce any major new features, but instead focus entirely on being a mission critical implementation of what’s been put in place for the short term releases. I truly believe this is the best focus for these types of releases on the distro level.

    That dynamic as I said earlier about Gnome and KDE is very different for upstream projects.

  153. David Moraes Says:

    Mark, I know that this is definitely not the place to post this, but I thought it’d probably be the best way to reach you about an idea for Ubuntu’s interface in the Karmic Koala. I know this is a highly personal statement, but hear me out. Ubuntu has always had brown as its default color and so changing the colors (while definitely a need) provokes criticism from the early adopters. I believe that what we are trying to achieve in Ubuntu (a unique interface, eye pleasing) can be accomplished by changing the default colors to light tones of yellow. It would not be a color far off from the familiar brown, but it would also give us a much broader array of options for wallpapers and themes. For instance, sunset pictures in Africa could be included…just me thinking aloud. I think Ubuntu would look pretty amazing :-)

  154. Kris Bloe Says:

    John hit the nail on the head ~

    We really need a version soon which focuses on bug fixing rather than new stuff.

  155. Ben Jarvis Says:


    I just wanted to drop this comment to tell you how much I appreciate Canonical and the Ubuntu project. I had played around with Linux for years, but more or less as a hobby. Once I tried Ubuntu (it was Edgy at the time), I knew I could use Linux and FOSS software full time. I’ve also switched my parents from Windows and several customers and friends.

    Thank you for all your hard work, the hard work of your staff and you infinite generosity.

    Ben Jarvis

  156. lyceum Says:

    I did not read all of the comments, so I may not be saying anything new.

    I always thought that the LTS releases WERE the meta-cycles. I see the 6 month releases as betas to the LTS. I think there is no reason to stop a bad thing, there should be goals for the regular 6 month cycle, and there should be long term goals (we want x, y, & z done in 6 months, and we will be working on a, b, & c for the next LTS). The nice thing about that is that the features can be “tested” on the 6 month cycles – as long as they are usable. Compiz was not really ready the first time it was standard on Ubuntu, but it was there for us to turn on if we wanted. It was in the repos before that.

  157. Nitinsen Says:

    For me, Ubuntu’s strength was the fact that everything magically ‘just worked’. My Dell Inspiron 6000 worked so perfectly with Ubuntu 8.04. This is something lacking with most of the other distributions I came across.

    However, I wished that I didn’t have to wait so long before new applications are available in the repositories. Most of the major problems only occur because we are trying to install something which is not yet supported or packaged by Ubuntu.

    So here is my suggestions:-

    1. An LTS update cycle of 2 years.
    (A new LTS product comes out every 2-3 years and is extremely stable and supported for 3 years)

    2. A hardware update cycle of 6-months.
    (All popular hardware released 6-months prior, will work without issues and is supported).

    3. A Software update cycle of 3-Months.
    (All major software released 3-months prior will be fully packaged and supported).

    4. Conceptual community developed conceptual updates which are dynamically released.
    (We need a number of official community projects, which respond to the zeitgeist and individual needs)

    How these 4 cycles are brought together, I’m not sure but I think is the minimum necessary to compete effectively with the OS market leader. I would but 1, 2 and 3 in one basket and help foster 4.

  158. Thom W Says:

    My thoughts boil down to just a couple of ideas. One, there is no “one throat to choke” if a schedule falls on the floor and disrupts a release. As a Linux OS distributor, your plans have to flexible enough to allow for changes, yet strong enough to know when to cut something, if the impact is negligible to the ideas of the release (go/no go), especially when paired with different companies/ventures’ release schedules. This speaks volumes for your company as it has to weigh your objectives against three really big external pressures: Kernel, window development (Gnome, KDE, etc.), peripherals (both closed and open source developers).

    With those “drivers” in mind, my other thought is that a company or team should always have at least two distinct paths. The first are strategic goals. What do you want version X.0 to look like, to do? What will differentiate it amongst the other X’s? I feel these are the LTS versions you are looking for. The second set contains implementation goals. What do you need to do to get to X? What minor steps do you need to pull in not only your own teams’ goals but to exploit (use to the best ability) the releases outside your direct control? I think this last statement is most important because while you may not be able to effect changes outside your environment, you will be able to react within your own framework.

    The two tracks are simple to state: Long term to define your vision; short term to respond to outside forces. However, I would like to add that I would personally like to see a third track of just pure development. The R&D would not follow a short or long term cycle, but one of milestones or perhaps just plainly, a budget.

    And think about a computer like a dog in terms of lifespan. A computer you bought last year could have technology that equates to seven years of a lifespan. So for an LTS plan, would it be best to cover not the bleeding edge but the majority of supported hardware? It would also help the consumer side to meet expectations to work (magic toaster) than to say load this version and wait till the point release. The LTS release should be less design and more test. I would rather have a single LTS every 32 months. Point releases should be planned for every 8 months. I don’t like the releases of every six months. It means that you are forcing events to occur in the same two months every year. By breaking it down to an LTS and three point releases every 32 months (the last point release should be shorter than the other two), it seems to me that you cover all your goals.

    I am sorry if this seemed so disjointed. I tried to distill three pages of notes into four paragraphs. You should stop by Durham some time. I’ll buy the first round.

  159. Chris Campbell Says:

    Thanks for asking for our input.

    I’m a desktop user, and I vote for 2 years. I was actually disappointed when the LTS releases slipped from every 18 months (I believe the original intent) to 24 months. I do like the integer year concept and finding a good time to sync with the annual conference / development rhythm.

    I take the LTS release and run that and I generally DO NOT mess with it from there. So I am stuck with the 8.04 snapshot until the next LTS release; and that can get pretty painful what with half the multimedia capabilities never quite right (e.g. Flash / PulseAudio messed up in 8.04). So far, I’m doing this on the same hardware platform — upgrading the OS while keeping the /home partition. By 10.04 I guess it might be time to upgrade hardware.

    I would be disappointed to have to wait until 10.10. Having been through the 6.04 to 8.04 wait, I can live with waiting until 10.04, but beyond that I start to consider a non-LTS release. And THAT would probably be a whole new mess …

  160. Sina Salek Says:

    Very good article Mike,

    You mentioned that Hardware guys prefer 2 years to benefit new hardware, that’s right but i believe that the design should be flexible enough to handle this kind of changes without breaking the whole things. it’s not always possible i know, things like supporting multi touch screen in applications is not possible without major changes, but it takes years for this kind of technologies to find their way into mainstream. at first they’re just experimental and then they’re expensive so not many people can buy them.
    Anyway i think 3 years is good, but that should be a really Bold Move :). For example major underlying changes in core for providing more flexibility. other features can be added without breaking backward compatibility.

    I’m a member of Drupal community, Drupal has a good release cycle in my opinion. they have a 1 year major release cycle but also support the previous version fore 2 years. It guarantee innovation and stability.
    Personally i think they should have support the older release for one more year. because lots of big sites,modules,themes,and books are depend on it. and having a little bit short major release cycle wastes lots of energy.
    One great thing about Drupal community is they’re trying to use automated testing for core, it allow them to have longer time before code freeze, so they can add lot more features. it’s a really great idea i think.

    So i think three type of release cycles is better.
    6 Month , mostly for maintenance and keeping it uptodate. wht? you already mentioned it in your article

    1 Year , adding new features which does not break backward compatibility but change many things. why? many softwares and codes might be based on the product, so everyone can benefit from new features without dealing it bugs and discontinued softwares. Also since lots of feature have already added and polished, development team have a better view of what the next major release should contain or support better, and there will be no need for end-less discussions about most how to implement those features. They can focus on most important things.

    3 Year , Major release which also breaks lots of things and mostly contains underlying changes that are not directly visible to end users.

  161. Capitão Óbvio Says:

    Windows 7 on October 23 — what that means for Open Source

    According to El Reg,

    “Acer, the world’s joint second largest manufacturer of PCs, has reportedly given October 23 as the date when Microsoft’s successor to Windows Vista will become available.”

    If that date is confirmed, it would be very nice if Canonical could announce a new Ubuntu release for the exact same day.

    The reason is simple:

    All the news and articles that would talk about Windows 7 will start to mention the free, open source alternative. David vs. Goliath, what a story! Ubuntu 9.10 will surf on Windows 7 waves.

    What that means to Open Source

    Ubuntu 9.04 is one of the best Linux desktops ever released. It has the usability you expect from a modern Operating System, and is very light in comparison to Windows or Macs.

    Canonical should use the following months to polish Ubuntu. Don’t add new features — think of Ubuntu 9.04 as “Ubuntu 9 RC1”, competing with “Windows 7 RC1”.

    But Ubuntu also depends on its partners.

    Firefox, for instance. Version 3.0 was fast and snappy when released. But now, after months of development, it is starting to crash more ofter than I’d like.

    Don’t get me wrong: Firefox is miles ahead of Internet Explorer 8. When comparing Windows 7 to Ubuntu, users will be also comparing Internet Explorer to Firefox — and Ubuntu wins.

    But we don’t have much time to fix the problems, so Mozilla Foundation should stop working on new features and focus on performance and stability.

    The same goes to OpenOffice. Differently from Firefox, I think it is much more stable and faster than previous versions. So, OpenOffice developers should keep their current focus.

    And the same goes to all the other important Open Source projects: GNOME, Evolution, GIMP, Pidgin, Brasero…

    Ideally, all the parts should be ready by early September. That’s not much time.

    Feature freeze now.

    We have a great Release Candidate.

    When Microsoft releases Windows 7, we’ll have the best Linux desktop, ever.

    Original link:

  162. Georgey Porgy Says:

    Why not just bump the release cycle to 8 months and see if thats better or worse and work from there

  163. Omair Hafiz Says:

    I have not read all the comments either and I am not a software guy by any stretch of the imagination – but in any case, here are my two cents.

    Time-based releases are excellent for a piece of software that is in a constant state of flux. It helps to organize the development process and ensures that stability (for the major part) is ensured as more and more features are added to the system. I have been using Ubuntu since 7.10 and was extremely pleased to see that with 9.04, my wireless was working out of the box and I could finally delete those compat-wireless files. In general, the way the distribution has evolved over the last couple of years has been excellent and has served to enhance my productivity and the overall experience of using GNU/Linux. There have been breakages along the way – currently 9.04 gives me a eardrum-shattering pc speaker beep on shutdown, I get error messages on boot up – but by and large, I realize that this is the price to pay for using something that is still in a state of rapid change.

    What I do not know, however, is when the state of change will end. More specifically, I do not have an idea of when the features currently slated for this particular piece of software will be fully implemented and tested. More importantly, I do not know if there Is a feature-cutoff imminent. For all I know, Ubuntu will continue to evolve as it has for the last five years – incrementally, without rounding off the edges and with minor breakages along the way.

    What I propose is that a meta-cycle (as you call it) cannot be based on time, but on core ‘meta-features’. A meta-feature could be something like hardware compatibility/support or enhancing user-level experience etc. Once such a meta feature is realized and fully implemented should there be a LTS release and a structural break in development.

    At some point however, GNU/Linux might have to realize the lessons that Windows XP has taught everyone – people will refuse to upgrade a 12 year old flawed system if it is suiting their purpose just fine!

  164. Menno Says:

    Major and minor cycles connect with the long standing traditioning of versioning in software-land.

    And for general usefulness of those cycles I recommend:
    (not necessarily in that order 😉 )



  165. Capitão Óbvio Says:

    Windows 7 on October 23 — what that means for Open Source

    According to El Reg,

    “Acer, the world’s joint second largest manufacturer of PCs, has reportedly given October 23 as the date when Microsoft’s successor to Windows Vista will become available.”

    If that date is confirmed, it would be very nice if Canonical could announce a new Ubuntu release for the exact same day.

    The reason is simple:

    All the news and articles that would talk about Windows 7 will start to mention the free, open source alternative. David vs. Goliath, what a story! Ubuntu 9.10 will surf on Windows 7 waves.

    What that means to Open Source

    Ubuntu 9.04 is one of the best Linux desktops ever released. It has the usability you expect from a modern Operating System, and is very light in comparison to Windows or Macs.

    Canonical should use the following months to polish Ubuntu. Don’t add new features — think of Ubuntu 9.04 as “Ubuntu 9 RC1″, competing with “Windows 7 RC1″.

    But Ubuntu also depends on its partners.

    Firefox, for instance. Version 3.0 was fast and snappy when released. But now, after months of development, it is starting to crash more ofter than I’d like.

    Don’t get me wrong: Firefox is miles ahead of Internet Explorer 8. When comparing Windows 7 to Ubuntu, users will be also comparing Internet Explorer to Firefox — and Ubuntu wins.

    But we don’t have much time to fix the problems, so Mozilla Foundation should stop working on new features and focus on performance and stability.

    The same goes to OpenOffice. Differently from Firefox, I think it is much more stable and faster than previous versions. So, OpenOffice developers should keep their current focus.

    And the same goes to all the other important Open Source projects: GNOME, Evolution, GIMP, Pidgin, Brasero…

    Ideally, all the parts should be ready by early September. That’s not much time.

    Feature freeze now.

    We have a great Release Candidate.

    When Microsoft releases Windows 7, we’ll have the best Linux desktop, ever.

  166. Primefalcon Says:

    Personally I think things are good how they are really, in a business situation where stability matters, I would keep to the lts version and only upgrade the next lts version when the current lts version I’m using is expired, that way you would get maximum stability.

    However as a user I like new features however I think in the future I might wait a month or so before upgrading my home systems just to let the majority of bugs get sorted before I upgrade.

  167. Halil Says:

    Here is my 2 cents…

    6 months cycle releases hardly ever has killer/ground breaking/major(whatever you call them) new features and the LTS releases are mostly the bugs fixed versions of the previous releases.

    There might be a problem with the way the new major features are introduced and presented, and following a different release cycle or using different names like meta/major cycle might help to fix this problem. However, the fact that Ubuntu introduces very few major features in total, specially compared to Fedora, remains the same. Unless the development resources increase(in-house, community contribution etc), this fact doesn’t seem to change.

    Im a windows geek/pro who is trying to switch his desktop OS to Linux permanently for a while(in which I haven’t succeeded yet). I keep an eye on Ubuntu since 7.04 and as well as watching some other distros as well. While I’m amazed with the ease-of-use(user friendliness) of Ubuntu, I believe as for the technical development, specially for under the hood improvements, Ubuntu falls significantly behind of Fedora. I just cant help myself saying “I wish Fedora is as user friendly as Ubuntu” or “I wish Ubuntu has as many development resources as Fedora has”…

    Mark, I believe the problem is a resource problem, rather than using a different release naming scheme or using a different release schedule.

    So, that’s my 2 cents…

  168. I Love My Linux Says:

    Interesting read……

    I found this blog post by Mark Shuttleworth to be very interesting.   Mainly because I know very little about the development process of open source software.  It outlines some interesting points and if you have any points, please commen…

  169. aussibear Says:

    Maybe do it like this?

    Non-LTS => Have annual releases. (Once a year instead of every 6 months.)
    LTS => Every 3 years.

    So its like…(assuming the new release schedule is implemented AFTER 9.10 release)

    10.06 => Non-LTS
    11.06 => Non-LTS
    12.06 LTS
    13.06 => Non-LTS
    14.06 => Non-LTS
    15.06 LTS
    …and so on.

    .06 because you have mid-year releases. :)

    The non-LTS 6 month releases seem a little too much for the Ubuntu devs to handle. There are “niggles” with each release that need to be addressed. This allows plenty of debugging and polishing time…That is important if you want to give the user a good experience with every release.

    Granted, it wont be as “cutting edge” or follow the “release early, release often” perspective like before. But a less buggy Ubuntu release will give a better impression on the consumer desktop crowd.

  170. Aryan Ameri Says:

    When I’m deploying Linux machines for office users, I always go for the LTS release. Same with anything I put on the server, for obvious reasons.

    These users do not care about new features, what they need is a rock solid stable platform. To them, the desktop is not something exciting in itself, it is just a tool. s

    As such, the LTS release, should IMO aim to provide the last and most stable revision of packages. If a LTS release was coming out right now, I’d still put KDE 3.5.x on it. I know that Ubuntu chose the opposite path with Firefox 3.0 for 8.03 LTS, but that was justifiable as various tests had shown Firefox 3.0 RCs to be even more stable than Firefox 2.0x

    On the issue of 2 years vs. 3 years for meta cycles, I’d much rather prefer 3 years, with a 5 year support for desktop and 7 years for servers. 2 Years update is simply too rapid for enterprises. Offices don’t change their desktops every 2 years. Most office only change their desktops every 3-5 years. A 3 year update would fit in perfectly with them. 2 Year update would not be so well received by administrators. Similarly, the current 3 year support window for desktop versions of LTS is too short. Microsoft supports its operating systems for at least 7 years, which is one of the reasons it is accepted in the Enterprise. I would say that an LTS version should at least be supported for 5 years on the desktop.

  171. cosmix Says:

    There are several reasons why the next LTS should be deferred to October 2010. But before we go there let me comment on the most basic issues here.

    One of the problems with Ubuntu is that — until now — the six month release cycle has not allowed it to place some more fundamental, important goals with regards to the many problems facing desktop linux today and start working towards them. Back in 2004, Ubuntu was a modernised Debian; expectations were low as it was the new thing, totally unexpected and as such it was more than anyone could have imagined. It was a success!

    In 2009 Ubuntu is one of the de facto leaders in desktop linux, with an important share of the linux installed base in netbooks and an increasing [but still small] share in servers. And expectations are high.

    Still, after years of promises of a revamped desktop, the possibility of getting it in Karmic Koala seems anything but realistic; the contributions of Canonical/Ubuntu to the kernel, GNOME, KDE etc. remain minimal and insignificant when compared to other ‘vendors’ of popular distributions [Novell and RedHat come to mind] and in some cases remain exclusive to Ubuntu. The project is considerably more ‘closed’ than, say, Fedora or Debian, steered by Canonical.

    Nevertheless, Ubuntu is a great project and a promising operating system. Today — if anything — the fact that it’s been used by so many and that it’s promised so much while delivering so little [over and above its competition that is] in the past few years means that parts of its structure and focus need to change.

    I believe that the release cycle, along with the lack of focus are part of this ‘stagnation’. Many of the things that are wrong with Ubuntu need considerably more than six months to get fixed; focusing on great experience [regressions between Ubuntu releases are increasingly common and extremely annoying even for experienced users, let alone newcomers], contributing back to upstream projects, steering the architecture and design of those projects and providing a polished and stable environment.

    Packaging GNOME and new versions of a few thousand applications and slapping on ‘Human’ doesn’t cut it and while the efforts of the community and Canonical are commendable, the results are often not enough. While Hardy was a mess, Intrepid and Jaunty were more polished; but at the same time they were minimally functionally improved.

    Compare this to Mac OS X’s improvement between Tiger (2005) and Leopard (2007). Huge problems pertaining to kernel performance, several subsystems, the desktop experience have been worked upon. And — I admit — the comparison is far from fair; Apple is a huge company and Canonical is a small one. But the magic of the Open Source community [and its hinderance] is that openness which allows a small company like Canonical to take existing work and improve it; all that’s missing is the focus.

    So, yes: It would be best to stagger long term releases to match the release large projects. It would also be best to focus more [and I don’t necessarily mean that Canonical should shoulder ever increasing costs by disproportionately hiring more people] on upstream projects and focus on key goals: desktop experience, performance, stability, hardware compatibility.

    Regarding the next LTS, I would very much like to see Ubuntu avoid the mistakes of 8.04; a buggy, incomplete release that took more than two months before it became worthy of use, let alone worthy of the LTS branding. All for the sake of bragging that ‘8.04 was on time’ and that the 6-month release cycle works. Well, it doesn’t. Not always.

    Aiming for a 10.10 LTS makes sense for very specific reasons too, however: Spring 2010 will most likely see GNOME 3.0/2.30 come out which should — ideally — be part of the next LTS release. 10.10 will be the best timed release for this as it’ll give enough time to upstream and Ubuntu developers/package maintainers to thoroughly test the code and iron out bugs. At the same time KDE will have probably reached a much more mature state. The linux kernel won’t be seeing too many changes in this period, but other projects that have been in the works for some time [pulseaudio, devicekit etc.] will most certainly be more stable and ready for an LTS release. To cut a long story short: spring 2010 will most probably not lend itself to an LTS release. The following fall will.

    Apologies if this was longer than the etiquette for comments on this blog allows. I am happy for this post as it demonstrates that, at the very least, you are thinking about the importance of release timing and synergies between vendors/projects. Open Source promises so much; I feel that what’s needed is more focus and cooperation.

  172. another_sam Says:

    See Vista. Well, GigaBytes have been written about the “Vista thing” among many places. Here for example. In my point of view, the lesson with KDE 4.0 and Windows NT 6.0 is that big jumps in software make easy to end in a big smash against the ground.

    This threat makes me review the needs of major cycles (“major” and “minor” cycles seem intuitive for me also).

    1.- Perception of significant changes. I know few things about the average-user motivations, but tentatively, I would be with those who say that users give more value to things “absolutely” better than things “relatively in comparison with the previous version” better. I mean, what matters is which is the best OS among all the available, not how much better is Ubuntu N compared to Ubuntu N-1. Once you have an absolutely better software (more usable than alternatives, and more functional than alternatives or not), the internet does the rest. (poorest approach to marketing ever, I know)

    2.- What to support for how long. For me, the case of Ubuntu 8.04 LTS is a good one. Ubuntu 8.04 came with Nautilus 2.22.2. And since then, it has been updated up to Nautilus 2.22.5 in Ubuntu 8.04.2. I think this is a reliable tactic: Choose stable (but no necessarily ultra-stable) versions at the LTS launch and freeze major.minor version; only applying patches onward (2.22.3, 2.22.4, 2.22.5, …). So, I agree with upstreams providing patches for packages included in LTS distributions. And this is more feasible if there is a …

    … coordination with other distributions.

    “That would make sharing patches a lot easier”. I totally do want this! Stressing indeed: We have to choose between make things twice (n-ice) or be a real alternative to proprietary software.

    About “best practices” for major cycles, I would point at one common-sense constraint describable as 4 rules:
    1.- A major cycle needs preconditions and these preconditions must be known and kept from the beginning of the work to the end.
    2.- Because of 1, superior layers of software should be designed to work with the eventual versions of inferior layers, not with the current ones.
    3.- Because of 2, it does not seem a good idea to design things based on deeply immature APIs.
    4.- Because of 3, alphas of GCC, X and should not be designed (nor implemented) in parallel. At the very least, they should grow with the offset of the alpha stage. “Pipelined Stack Development”, in cool words.

    About 2 or 3 years, I would say 2 years. Someone should explain me why 3 years is not 50% more reckless than 2 years… 😉 Also, I think 3 years is too much from the point of view of functionality, at least currently; it could mean up to 2 major versions of browser and office suite behind the current stable one.

  173. Jon Rutherford Says:

    Like sigh (above) I find something, in fact many things, broken in new releases that worked for me in prior ones. I will no longer consider using anything but an LTS release, for that at least gives me the feeling that more troubleshooting and care went into its preparation than into others, and that its problems may receive more prompt attention than otherwise. I’d also like to see the animal naming system dropped in favor of dotted names (e.g. I believe people would feel less “guilty” about reverting to a previous release that worked better for them, than if they have to abandon a new pet and take back old Fido from the shelter. Mainly, though, if I could have just one wish about this, I’d like to see releases come out only every two or three years. Let them be updated in the meantime, but at least give the impression of having been fairly solid to begin with.

    In the US, one form of advertising we often see is “New and completely redesigned for 2009!” OK, GM or whoever you are, if your last car was as perfect and wonderful as you said it was, why did you have to scrap the design and start all over? I think this is relevant to software — and software advertising — as well.

  174. George Fragos Says:

    As a user I look forward to the 6 month cycle. As a developer since 1964 I find the 6 months admirable. As a VP, Engineering I strove for a 1 year delivery cycle but frequently had a phased development plan that might cover 3 years to achieve with releases every year. The longer plan allowed for bigger goals not achievable in a single year. Getting something to market is important as well. We’d specify and design to the long term end goal but develop to a one year phased shipment schedule. On ocassion a feature planed for the next release might slip but we slipped that feature into the next release rather than delaying the release we were working on. A yearly breaking point also gave us the opportunity to re-evaluate the long term goal. I’ve taken this approach successfuly for a number of years with system products that included hardware and software development.

  175. Tony Sutorius Says:

    Gidday from New Zealand.
    Mark, I’m a business owner who has had Ubuntu deployed through the administration functions of my documentary production company for about three years. We also use other linux distros (not Ubuntu yet) on our servers. I would like to propose that from a small organisation’s point of view, the salient issue is somewhat missed in the LTS concept.
    I am really impressed with the speed Ubuntu has moved and improved, and offer all due kudos to all concerned. For sheer drag-race speed in development, the six-month cycle seems to be excellent.
    However, for us the real hassle is the little things that never quite get fixed…. things like the painful hacks still required to permanently map network drives that all apps can see, or to make basic multimedia functions like DVD replay work.
    I’m not in a position to be certain, but my impression is that the six-month release cycle means there is little time for such niceties to be addressed before all development attention moves to the next release.
    Equally, six months is a short time for the documentation to catch up, which becomes rapidly apparent when trawling for answers to issues such as these. One often winds up wading through fragments of documentation intended for previous releases.
    It seems to me that my organisation would benefit greatly from an occasional “super-release”, developed (perhaps over a slightly longer time) with an extra couple of months spent on pre-release testing, polishing and documentation.
    Perhaps Ubuntu could profitably contemplate something like a 6 month – 6 month – 9 month release cycle, with the occasional longer cycle being a more highly polished “LTS” or “Deployment” edition?
    Keep up the good work.

  176. Nobody Important Says:

    As an everyday user of Ubuntu, I simply don’t have the time or space to upgrade my OS every six months. I would use 8.04, but it doesn’t support my Wi-Fi like the others (if it did, I would; I use Debian Stable instead).

    I’d like to see the non-LTS built on top of LTS versions – so, 9.04 is an addition to 8.04 LTS. A simple add of a repository, which can be GUI-ed with a click of a button. That would be easier than having to do the huge slog of the updates as-is. I can only say of the present situation: ew.

  177. Dave Mawdsley Says:

    My main business laptop is a Dell Inspiron 1505n, my server is a ‘homemade’ whitebox machine both with Ubuntu 8.04 LTS. (desktop & server) My on-the-road computer is a Dell Mini-9 running Ubuntu 9.04 Desktop. I need the stability of the 8.04 LTS for my office, but am happy to show off 9.04 on my Dell Mini-9. (It was running 8.04 but I didn’t like the Dell ‘version’ of 8.04.) Personally I like the LTS cycle and think that it’s about the right length of time on my critical computers. The on-the-road Mini will take a successful recent release if it works as good if not better than what it had. If the recent release doesn’t work well enough, I’ll just revert back to the latest LTS and then wait for another 6-month cycle to try again. By the way, 9.04 ROCKS!

  178. Ajibola Okubanjo Says:

    As a user and not a developer, I just want a release that I can install on my friend’s pc and find the wireless, sound and graphics all working fine. I have been using Ubuntu now for about 4years now and I have enjoyed all the releases. But the upgrade from Intrepid to Jaunty didn’t really got me excited, yeah there was OpenOffice 3.0 but other distros had got it for like months already and then there was the unnecessary upgrade of Amarok to 2.0(which I have removed now). The upgrade to intrepid from hardy was by far the best upgrade that I ever done on an OS. I like long term cycle release, but what I don’t understand is why you have to keep calling them new upgrades. In my opinion new features that were released in jaunty should have just been released as an update to intrepid and the next major release should have been the now upcoming Karmic Koala. Always remember its not the developers that make a great distro, its the users !.

  179. Mike Cornelison Says:

    Managing Release Cycles


    1. Releasing too soon (broken or crippled code) is pointless, therefore
    keep such releases within the developer/tester/documenter community.
    What purpose was served by releasing the buggy and crippled KDE 4?

    2. Release management must facilitate both evolutionary and revolutionary
    development. The system should not hinder the rate of change.


    1. Use a continuous release methodology as long as the kernel APIs
    don’t break compatibility and force a big-bang release.

    2. Applications should normally release at times chosen by their own
    developers. Releasing 1000 apps in one big bang has no advantages.
    Users should choose when to convert to a new release, within the
    usual dependency constraints. This can be done now with Update
    Manager, but the UI needs improvement.

    3. Do security updates and bug fixes immediately (no change).

    4. Revolutionary changes (e.g. KDE 4) should be implemented with adaptor
    layers supporting the prior API (KDE 3). Applications can convert
    asynchronously to the newer API, and users can elect when they make
    application changeovers. The older API (adaptor layer) goes into a
    bug fix mode and eventually gets dropped.

    Unrelated Opinion

    The problem of release cycles is not as important as other problems you
    should be working on: standardise packaging system, and standardise APIs
    for applications. Bottom line: make it easy for application developers
    to create applications that run well on any Linux distro that cares about
    standards. Windows apps created 10 years ago still run, and this has not
    constrained the evolution of Windows (MS has big problems but this is not
    a causative factor).

  180. Matthew Lye Says:

    6 month cycles are good from a development and engineering perspective but you run into two problems.

    1. You need to have regular IMPACT updates that people can point to and say wow, I can see the difference.
    2. You need to have time for people to develop that next big thing, and it always has to contain an interface overhaul.

    Let me qualify this a little more. Microsoft are experts at this, they release regular service packs that introduce the odd new feature, somewhat like the Ubuntu regular releases. They try to address problems but typically you know things will be the same. At the same time they aim for a big release with significant UI enhancements every 2 years, its sometimes delayed, but you know its coming. They do this so they can do the big impact changes, yes it breaks things but everything looks so good. The organizations play with it a little, then after another service pack release they all upgrade.

    Im not saying Microsoft is anywhere near perfect, but they have worked this out down to a science pushed by the marketing machine that is Microsoft. Im thinking that we need to change the way we look at releases. Make the regular releases incremental, and do a big change every few years.

    That being said I agree with the reason for moving the LTS to 10.10, but you will annoy organizations that were planning on the LTS for deployment. That being said with changing the methodology around slightly that would not cause a big impact and LTS releases could be delayed for big ticket improvements as long as regular 6 monthly updates occurred.

    Also I think we need to look beyond brown and add other African colors, like the ones in the ubuntu logo palette.

    Just my 2 cents.

  181. Jan Evert Says:

    There are a lot of comments already and I didn’t read more than half of those.
    I really, really like the LTS releases. It means that I don’t have to visit my Ubuntu using friends, that are not that computer-literlate, every 6 months to update their computers. Except that 8.04 LTS needs some updates on the HW support. Also a key number of often used packages such as firefox, thunderbird and possibly OOo need an update. And, as a programmer, I’d say that newer compilers and things like JDK, eclipse and such are also needed.
    Looking back at those lines, I’d say that LTS is not that useful for a lone desktop because the SW landscape changes too quickly. For a company LTS might make a bit more sense, except for the HW support because companies also need new desktop HW every now and then.
    I don’t care enough about my desktop that I consciously decided about KDE vs. Gnome. So I don’t want to comment on their meta-cycles. But it seems natural to me that those large packages, and also OOo, do have large cycles. But does that really mean that Ubuntu needs to handle that? Instead, why not allow for ‘apt-get install kubuntu-kde3’ and ‘apt-get install kubuntu-kde4’? Yes, increased support, but not for all of ubuntu.

  182. D1Knight Says:

    O.K., here is my 2 cents. I am new to the Linux Community (less than 1 year). The every 6 months release cycle is great and fast, but (IMHO) 1 final release per year (LTS every 2nd year) would be more than enough and still effective. Changes to help for only 1 release per year, would be to extend a little longer support to the “non-LTS” edition (+6 months or so). Then ideally add tested current updates of packages (GNOME Desktop, Compiz Fusion, etc.) to stay current until next year’s release. Why? Again IMHO, this I believe will give everyone ample time to invent-develop new features and test more completely (squash bugs), also time to make broader compatibility to more PCs. Just my 2 cents.

  183. Peteris Krisjanis Says:

    What I would like to see is to abadon regular releases for users and just leave LTS as recommended and used. For LTS, agressive regression checking and feature checking, plus bug squashing frenzy. For regular releases – treat them as now do, be open about bugs, and recommend them only to users which knows what they do.

  184. Daniel Hedblom Says:

    Hi there and thank you Mark,

    I think longer release cycles would work much better than today if coupled with backports of popular applications. If a user can have the latest versions of OpenOffice, Firefox and Konqueror etc many do not have a real need or want to upgrade just for the fun of it. Access to backports would ofcourse have to be easy and obvious to a user.

    Releasing to often has a high drawback for normal users. The moment most bugs have been worked out its time to start over. Use LTS as the supported releases and the rest as development releases. Backport the most common apps often.

  185. greg toler Says:

    first off i just want to say that i truly love my ubuntu 9.04 (9.04 set-up just for me) i believe that a yearly release would be better. then you would have time to make more advances like 8.10 to 9.04 was . i would really enjoy an auto installer and a easy cross platformmer . i`m just a middle age man who got feed up with microsoft found ubuntu 7.10 and now here to stay and learn . thank you Mark Shuttleworth

  186. G Says:


    Currently Ubuntu goes with 6-month “snapshots” of just about everything, with lots of integration and fixing activity as the release approaches, and then several months of updates.

    You already have the PPA system, which allows people to track the bleeding edge of software they care about.

    Why not add time-based PPA release scheduling, and stop releasing big projects like GNOME, KDE, etc as part of the 6-month Ubuntu cycle in the main repositories? Ubuntu itself could focus on providing core services to applications, rather than packaging everything and the kitchen sink.

    Let those projects define their own “bleeding edge”, “testing”, and “stable” branches, and have their own release schedules. I don’t know if you’d need to go as fine-grained as a 1:1 package-to-ppa ratio or not.

    An Ubuntu Core PPA could bring in all the standard packages, the kernel, etc. An Ubuntu Standard Desktop PPA could depend on the Gnome PPA’s “stable”, which would be updated with GNOME releases. And so on.

    You could extend “Add/Remove Programs” to allow user to pick stable, testing, or bleeding-edge versions of each package, and present a list of PPAs updated from launchpad.

    I want to see the end of situations like the firefox-3-included-in-stable-before-it-was-released one. The 6 month snapshot release process might make sense from an integration standpoint, but it’s really quite arbitrary and suboptimal when your upstream isn’t moving in lockstep.

    This is just me whiteboarding. Not sure if any of this is feasible in cold, hard reality.

  187. John Alatalo Says:

    I think when Ubuntu 9.10 coming it be better to do a stabile Ubuntu. 6 months cycle is to often. If the design will be great in 9.10 Its better to come with a new version every 12 or 18 month. New things can be installed by ordinary updates or service packs.

  188. Eric Pritchett Says:


    I think the biggest key, as you mentioned, is collaboration. Working with projects like Debian, Gnome, Open Office, Fedora, OpenSuse, and others is the most important not necessarily the release date itself. With that said, I would like to play around with the idea of having one release, an 18 month LTS release. The catch is that users would have the option of enabling a repository to receive the latest stable apps, drivers, etc. So if there’s a new version of Evolution, Gnome, Open Office or NVIDIA driver the user can update their system automatically. The key with this is to make sure it never breaks anything. If it breaks the system then it gets deferred until the next release. The length of support would be 3 years, so at any given time you would never support more than 2 versions of Ubuntu on the desktop.
    I think this will keep a lot of people happy. Home users can also get the latest and greatest even quicker than the 6 month release cycle while Enterprise users can deploy either every 1.5 years or 3 years. This would make marketing easier and provide enough time for developers to coordinate with each other.

  189. John Alatalo Says:

    In the Swedish IDG 39 % want a Ubuntu release every year:

    I agree.

  190. Tim Says:

    In my opinion, a 6 month release cycle creates a rushed and buggy impression to the end user. I think the enthusiast/tech crowd get the most out of the 6 month release, but potential new users can be chased away. I do like to see an LTS every 2 years at the longest. I personally would prefer an 8 month cycle for regular releases. That would net you 3 releases every two years. You could use the extra two months to polish up issues that arise during alphas and betas, while leaving the door open for any major updates (such as the Firefox 3 situation prior to 8.04) in that last two months of development. Then every 3rd release (every 24 months) would be an LTS. Simple, but I feel it gives a bit more breathing room for developers to create a more polished presentation on release day. I also like your idea of postponing the next LTS til 10.10. If that were to be the case, and the idea I mention above was implemented, here would be the potential release dates leading up to the next LTS:
    9.04 (released)
    10.01 (Karmic)
    10.10 (LTS)
    12.10 (LTS)

    Not sure how those dates would fall with Gnome and KDE cycles, though. That might be problematic? Thanks for the opportunity to provide feedback! I really enjoy Ubuntu.

  191. Tim Gepfrey Says:

    I think we should all learn from M$ mistakes. XP was out too long, anything after that was bound to meet stiff resistance. A two year release cycle is the absolute maximum for any distribution. M$ doesn’t innovate, Linux does. The big innovations should be taken in the six month releases and the bugs worked out for LTS releases, there is nothing wrong with a direct and simple name like “LTS”.

    From a business stand point, installing a new operating system every six months would be an IT guys nightmare, give the small business guys a stable LTS to work with and his 2150 employee vendor just might say “My IT guy should see this”.

    If Ubuntu ties its LTS releases to the Debian or KDE release cycle you should be prepared for major improvements in other areas like Open office or when the MP3 patents run out. Establish priorities that are VERY flexible.

  192. Jonathan Says:

    LTS releases should be tied as closely as possible to RHEL releases in order to allow us to leverage the server vendors’ (Dell, HP, IBM, Sun/Oracle, …) testing tied to RHEL releases.

    *** The value of this testing ALONE pretty much trumps everything else in importance to providing a robust solution with a broad base support for current server hardware. ***

    It would be nice if this were not the case, but it is.

    For example:
    If RHEL6 release scheduled for Q1 2010 two options for Ubuntu might include:

    1. Align the 9.10 base release aggressively with the kernel/gnome/firefox/openoffice/x11/wireless versions targeted for RHEL6 and declare 9.10 as pre-LTS with the gold-LTS version being 9.10.1 for release in q1 2010.

    2. Align the 10.04 base release with the next versions of the core distro components post RHEL6 in the hope of picking up the initial RHEL bug fixes from the upstream sources.

  193. jiu Says:

    Hi Mark, thanks for an interesting read.
    As some other commenters have noted above, the thing that struck me is that the reflection to determine release cycles is all about developpers, and not about what users want (apart from the 2-3 yearly release to accommodate businesses). As a former user of Ubuntu for nearly 2 years, I felt that the Ubuntu distro was never stable enough for me. I’m now using Archlinux which is considered to be more bleeding edge than Ubuntu. However, their packages get tested for a month or so before being released. This results in a very up to date and still quite stable distro. I also have a problem with the system of LTS release. In my opinion, the focus of these should be on stability more than on the length of support. This is what users are expecting. The 8.04 was a good example of the silliness induced by the inflexibility of the release schedule. Pulseaudio was introduced while still very buggy and for a lot of people sound didn’t work for some time (that was my case, and one reason why I dropped Ubuntu). People expect stability from the lts labelled release… at some point, you have to introduce quality criteria into the picture. If something important doesn’t work, then don’t release (or at least not an lts!)

  194. Leroy Says:

    Hi Mark,

    9.10 6 months release (October)
    10.04 1 year release (April)
    10.10 6 months release (April)
    11.04 1 year release (October)
    11.10 6 months release (October)
    12.04 1 year release (April)

  195. Daniel-U Says:


    some points:
    – I prefer full-year-cycles, not “30 months”
    – It would be difficult to link the Ubuntu releases with releases of other groups, maybe we should forget about that
    – As said above, we have essentially two kinds of users, those who like long running versions and those who like everything to be as up-to-date as possible.

    The current system is basically ok to me. My suggestion:

    Big step version: Every 2 years a new version, maybe even with a “break”. Average users, manual authors, trainers, companies can concentrate on it and don’t have to re-learn every six months. This Big step version should be advertised and shipped, unless somebody wants explicitly a more recent version.

    Small step version: Every six months comes a new version with minor changes, to keep up with the evolution of other free software, OpenOffice, Gnome or hardware. This is the version for the dedicated fans and those who have trouble running a peticular piece of hardware that would not work in the last Big step version.

    Support and attention of trainers: For a Big step version 4 years in total, for the current Small step version the time when it is current plus one month.

    I believe that to average users the many versions and names we have now are very confusing. Keep it simple, for example call the next Big step version “Ubuntu 10” and the following Small step versions “Ubuntu 10.1”, “Ubuntu 10.2” and “Ubuntu 10.3”. The next will be “Ubuntu 11”, meaning the next Big step version. Isn’t that much simpler?

  196. Kenneth Degel Says:

    Great read, I think it would be great for Debian and Ubuntu (and other Debian/Ubuntu based OS’s) if you guys could come to some agreement about having a ~2yr LTS/Stable release. I know how the Debian/FreeSoftware/RichardStalman people can be (rock headed?) so Godspeed to you my friend!!!! I love the Debian package management system so I hope Debian-based concurs all :)

  197. Whytehorse Says:

    As a user, I plan on upgrading annually. I usually set aside a week and hope for the best. I time it so it doesn’t affect my work. Therefore, it’s very important for me to have an annual release cycle in Ubuntu. It’s one of the reasons I prefer it.

    As a business owner and consultant for businesses, I upgrade servers on a 3 year cycle due to hardware warranties and Moore’s Law. This is actually a pain in the butt, however it is very cost effective and fits most business models. Typically, after 3 years of continuous use, servers become prone to hardware failures and they’re out of warranty. So to save money, we buy new hardware and install the latest release. 2 years is also a common figure.

    You should make some kind of service pack model for major changes in-between LTS releases so people can incrementally keep up to date(and test changes). For example, a new apache version that would break existing sites… That could be be released as a major update and people can try it, roll back if it fails, and plan if they have to fix something when the next major release rolls out. After so many service packs are released, it makes sense to just download the newer release rather than the old release with all the service packs. See what I mean?

  198. zhurai Says:

    personally, I’d say to do shorter release spans than 6 months

    or do rolling updates like how arch does, but that’s just my humble opinion >_>

  199. UnHa Kim Says:

    Dear Mark.

    I used ubuntu as my main desktop for more than 4 months and
    as the main DB server(6.06 LTS, 8.04 LTS) for about 3 years and much grateful to your devotion to free software.

    I hope Canonical keep leading “free software for everybody” movement whatever your motivation is profit or realization of personal dream about free software.

    In the meantime, I hope Canonical remain self-sustainable as a private company.

    Under not so normal economic circumstance these days, adjustment to release cycle based on the business requirement like keeping cost minimal while satisfying potential customers could be very good idea for you and also for users and community.

    While current economic situation is a big challege, also it is the biggest chance to change status quo after big bold movement of Ubuntu distribution creation.

    I hope you get understood, agreed and respected about your decision about schedule management as a community leader and a hope in free software movement.


  200. alan cocks Says:

    I think the current LTS cycle is a good way to offer a long run of trouble free (and excitement free) use.

    I am in contact with a lot of newcomers from Windows and I offer them LTS, with the exception of cases when they say they have newer hardware, in which case I offer the latest version, to give the best chance of drivers.

    The LTS interim images such as 8.04.2 are an excellent way of consolidating LTS benefits for newcomers because the latest drivers and fixes are incorporated into a live CD and first install – frequently a crucial rite of passage for a newcomer.

    Although I am not a developer, I find the 6 month release cycle exciting and always run the latest release in addition to the LTS daily workhorse. I like the energy that the 6 month cycle encourages.

    If there are weaknesses in a release, it is easier to live with knowing that the LTS version is working well and stable. I think an unfortunate exception might have been the introduction of pulseaudio in 8.04 LTS and 8.10, both gave me some problems until later patches presumably arrived, and helped, not sure of details though.

    The LTS interim images (8.04.2) can be a great help in such cases for newcomers.

    Major changes: I think these can be worked in pretty well ad hoc, but please avoid LTS versions containing anything flakey or not well proven.

    And – thanks!

  201. utnubuuser Says:

    I enjoy seeing the fantastic progress from “release” to “release” on the six month release cycle. I found Ubuntu at 7.04 and was impressed then. I’ve read plenty of criticism from “people-in-the-know” about the supposed lack of progress from “release” to “release”, but from the perspective of a non-geek-end-user, the steady improvements at every release are grand. At each new release something that was already good about the OS seems to have improved by another degree or two, and some new and interesting function or feature’s been added. Cool.

    I’d agree with the poster who emphasized the importance of consistency. – Means a lot more than “the latest and greatest”. I think the average hacker couldn’t care less about being “mainstream”, but it means much those of us who only use the various distros. “Mainstream” means my boss can to let me use it, thusly squashing Bug #1.

    If I’ve a beef about the fast release cycle at all, it’s that it causes me to antissipate the passage of time.

    I feel that the knowledgeable/skilled Gnu and Linux users/programmers/developers like the promise and challenge of a six-month release cycle because it assures their work is state-of-the-art and at the forefront of development; But the less knowledgeable users, and those “selling” the OSs, who are also part of the communities, and who’s contribution to the OS/community is limited to tasks such as responding to un-answered forum posts and assigning bugs to packages, would benefit from a clearer distinction between the two types of releases, and maybe a slightly longer support period for LTSs.

    I personally would love to read that Ubuntu and Debian have achieved greater synchronicity. – I think, from a marketer’s perspective, this would be a definite plus. Debian is not “just another linux distribution”. – Ubuntu really shines a light on Debian, and conversely, Debian’s well-earned cred is a big part of the reason why and how Ubuntu shines so brightly. I think, Mr. Shuttleworth, you are aiming for the stars again.

    I think you’re on the right track with the 2-year LTS release cycle, and the in-betweens are nice. Seems to me several distros’ maintainers and environment developers think so as well. (Imitation being the greatest form of flattery).

  202. Tim McNamara Says:


    “Generation” seems to be a more appropriate title to grand cycle for meta-cycles. Each generation implies a different way of looking at the world. From a motivational perspective, each generation has its own goals and aspirations while drawing from all previous generations.

    It’s interesting to me that you would consider the x.0 version as immature, and x.y as the one we should stick with. My preference would be for applications to use aplha/beta and then release a x.0 version for the stable + complete version.

  203. Type Mark Shuttleworth - Socionics Forums Says:

    […] his last blog confirms that. Mark Shuttleworth Blog Archive Meta-cycles: 2-3 year major cycles for free software? Therefore, Ubuntu is Gamma 😛 __________________ ILE ( ENTP ) Shock Intuition, Diamond Logic […]

  204. Lin (since someone took Evan :) Says:

    Mark when are you in the US? (I am still not convinced about Ubuntu, you will have to try harder :p)

  205. Nippur_L Says:

    Hi mark, I think 8 months versions and 1 LTS for 2 years.-

    9.10 kk
    10.6 LL
    11.02 MM
    11.10 NN

    P. D: my English id very bad, I speak Spanish (Argentina)

  206. David Gerard Says:

    Hey, a question. Is discussion of Mono on the forums really leading to threats of bans?

  207. Bilety lotnicze Says:

    Id would say that it really depends on the coders themselves – you cant just categorise a general trend. The more people involved the messier it gets. The more of them have something else to do ie. finally get out of college/ get married (not to mention kids :P) the less time for projects. I know i havent participated in some of the software thats still around but ailing.. Initial awe and euforia gets killed by real life :/.

  208. Victor Says:

    I just read that 64Studio ( is going to use the Ubuntu Hardy LTS package repository for its upcoming 3.0 release. Although the kernel and the core packages will be custom built, probably from Debian sources, the rest of the system and all the universe packages will come from Hardy. I think in large part this is because of LTS having three year support (which they can rely on for the next two years), and the fact that LTS has a fairly stable release cycle, so they can rely on that with more up-to-date packages than in Debian Stable. It seems the lack of a predictable Debian release cycle is the driving factor in this move. So this further supports your call for stable release cycles.

  209. Bilety lotnicze Says:

    I think 2 years release cycle is quite fine – as you mentioned it fits in more with the hardware cycle, however that at the moment seems to be speeding up with better and better hardware available every 6? months. In two years your top of the line use-to-be-computer is trash.

  210. Eapen Says:

    Where is the new look for Ubuntu as promised in the Karmic UDS ? Could you please post it here

  211. UbuntuLinux-fr Says:

    Lectures en Anglais #6…

    Voici une sélection de billets en Anglais, parus sur le net et sélectionnés pour vous par Comment supprimer Mono d’Ubuntu 9.04 (présentation d’alternatives à Tomboy/F-spot) Une petite FAQ sur le passage sous Jaunty Un billet de Ma…

  212. Mostly Anonymous Says:


    First of all, let me say that I really appreciate what you have done for Linux! You seem very in touch with real users needs as well as those of the developers. I also like the fact that you are willing to have open conversations with the community, without necessarily presuming to have the answers.

    From my point-of-view, the biggest concern is providing a solid operating system for users. I think Ubuntu can do this, and grow both its brand, and the Linux brand simultaneously. I see three main elements of this:

    1) Breadth of hardware and software support
    2) Consistency of hardware and software support
    3) Depth of hardware and software support

    I feel that #1 and #3 are mostly developer’s responsibility, while #2 is the responsibility of the distro. I applaud your efforts in kick-starting #1, but long-term, when the Linux brand is established, I don’t know that distros need to actively do this. I hope that as the intensity lets up somewhat, you can redirect your “management” efforts toward the next two, and really brand Ubuntu around consistency.

    Consistency is hard to do right in the FOSS world. As I currently see it, you have two responsibilities:

    1) Prevent regressions
    2) Manage large changes

    Preventing regressions is best done by testing, which requires both time and resources. I believe Ubuntu should invest in more and better testing capabilities to essentially reduce the level of regressions to just under the Just Noticeable Difference (JND) threshhold. That’s because regressions mask the positive, and have a disproportionate effect on brand perception.

    Conversely, in order to manage large changes, I also believe JND needs to be managed. Noticeable changes need to be marketed, and need to “just work”. As a user, I’m not sold on Ubuntu’s current cycle marketing. I love the release naming, but 6 month cycles for new names is too much. I feel it is below the JND threshhold for users like myself. I would much prefer the names to be associated with the LTS, while keeping the 6 month cycles as “release often” intermediates that are more analagous to Service Packs, as has been suggested earlier.

    In this way, you’d get Liberated Lemur, say, for 2-3 years, with 4-6 six-month cycles. My feeling is that the release cycle within any named release should look something like this:

    Liberated Lemur 10.04 (LTS): Minor feature and maintenance release
    Liberated Lemur 10.10 (Lemur.1): Minor feature and maintenance release
    Liberated Lemur 11.04 (Lemur.2): Major feature upgrades
    Liberated Lemur 11.10 (Lemur.3): Minor feature and maintenance release
    Liberated Lemur 12.04 (Lemur.W): Wildcard*
    Liberated Lemur 12.10 (Lemur.4): Major feature upgrades

    * A variable release cycle, that could one of: major, minor, or none

    I feel this would provide the following:
    1) An LTS that is based upon minor changes, and presumably rock-solid.
    2) Early cycle is stable, which is what new users want and expect.
    3) Multiple opportunities (2-3) for major feature upgrades
    4) Late cycles can bring in new features, and work towards stabilizing them before the next LTS
    5) More minor release cycles than major ones.
    6) Wildcard provides flexibility react to what is actually happening tactically, or possibly to do something completely different.
    with regard
    I believe we need to instill a development culture that does more stabilization work prior to a major release. I still see too many things broken in major releases. We need to find a way to cut the cord, allow feature development to resume, patiently press forward with testing and bug fixing, and then release.

    Oh, and with regard to naming the cycles, I wanted to throw out the term “epicycle”, although to me it sounds too “meta”, and probably has negative connotations.

  213. mah-kittehz Says:

    The current system is good, but establish the release after the LTS as being like a beta. This would allow devs to make big changes, while letting non-power-users and businesses stick to LTS’s and releases just before them.

    If it takes more than 6 months to fix the look, do it.
    Also, have a new loading bar for each release. That’s my favourite every time. (well, 8.04-8.10 hurt my eyes, but 8.10-9.04 was amazing)

  214. mrAshley Says:

    What about a rolling release with ticks and tocks.

    What I mean by this is a constantly moving picture of the cutting edge of open source. Always having the newest packages available and being added. This would satisfy developer need for few new stuff.

    Ticks would be every 3 or 6 months where Jane Average who uses the computer casually but loves frequent upgrades would sit. These freezes simply be a snapshot of the rolling release frozen in time and bug-fixed for several (12-18) months.

    Tocks, on the other hand, would be every 2 or 3 years as the culmination of the best practices (by popularity?) of the last several ticks amalgamated into one release as a tick, and then as a tock after a testing period has passed.

    Just a thought.

  215. wanda Says:

    Time to drop an idea. I think Canonical should halve the number of releases, and
    the time a release is supported should double.
    I realize that many more water from the Limpopo must flow all the time comes.
    The current release cycle of Ubuntu was originally a great innovation in the Linux
    world. Now the use of Ubuntu 1% is passed, requires the resolution of Bug
    Number 1 (https: / / a different strategy: The focus should
    shift to use by the mainstream instead of “innovation . Against this background,
    the advantages of such a major release cycle:
    – When in the air longer versions, is the pay for time to invest in the development
    of drivers. I think that is the big stumbling block for Linux. Nothing is not
    annoying than software running on your hardware.
    – When the number of releases is halved and support time is doubled, each version
    is a version LST. At this moment the rest LST current release still support as much
    time as the regular release. The advantage of a LST-version is currently not
    available for PC manufacturers. Double support time solves the problem.
    – The completion of each version is better. If there is an annoying bug, it can
    simply be addressed instead of the user to wait for a new version (with new bugs).
    – The naming is tighter: Ubuntu in 2009, 2010 Ubuntu, Ubuntu in 2011 etc.
    – I have something else to do than install a new version to access new software.
    Stop to enjoy the regular updates!

  216. wanda Says:

    Moreover, the Windows platform in Java safer already Ubuntu 8.04 LTS.
    Java is still not updated to 6.0.13.
    And that is a security update.
    Sleep the update manager?
    8.04 LTS = Long Time Support!
    Greets Wanda.

  217. wanda Says:

    wanda says: (permalink) This comment has been flagged by Akismet as potential spam, and is awaiting moderation.

    O no … Not spam.

    This is my full opinion and not SPAM.
    This write transfer is Google language.
    Greetings Wanda.

  218. Fred R. Says:

    A LTS release should be released only if working. Dapper had been postponed for 2 months (becoming 6.06) and who care ?
    Hardy had been released too early, and only worked 6 months later …
    Jaunty is the most stable Ubuntu release ever …
    I think the biggest mistake to avoid, is trying to put so many new cutting-edge features in an LTS release. If 10.04 is crap, and 10.10 is fine, let’s have this one to become the next LTS …

  219. David Says:

    I must say I concur with Cosmix’s view about Ubuntu being one of the “de facto leaders”, and, indeed, many commentators have noted that Ubuntu, for many, is Linux (for good or bad). So it does not need to prove itself anymore, and i have, along seemingly with about 1/2 of those posting here, considered the 6 month release schedule is sometimes a little rash. For new users, it just has to work, within the bounds of it being both a new experience and not Windows, so I would rather go for a flexible release date than some dogmatic, “it is tuesday so we must release” philosophy, and ensure that, within bounds of reasonableness, it does work. For myself, I tend to end up skipping a release, so will move to Jaunty soon after the wrinkles have been ironed out.

    Alignment with the Debian cycle seems to have a great elegance, and they can orbit around each other quite happily.You can extend the whole planetary metaphor as far as you want as a replacement for “cycles”, by the way!

  220. LanoxxthShaddow Says:

    I was wondering today whether it would be possible to introduce rolling releases only for certain applications that are unlikely to affect other programms or version incomplatibilities or if there is an issue provied an option for people that want the newer version.

    This would both satisfy people who need stability and people who need the latest version. Especially for user space programms, the less close to the core system the programm is the less likely is it to break anything if you upgrade it. Thus small programms like geany or some games would be candidates for rolling releases.

  221. InTheLoop Says:

    I agree with you in two ways. First, short release cycles are great, but they HAVE to be accompanied by less-frequent, longer supported releases. I can barely keep up with short release cycles on my own computer, so I can’t even imagine trying to upgrade 100+ computers every 6 months.

    Second, I really wish that at least the longer-term releases were synchronized across the entire free software world. Ideally, though, this might be staggered. For example, kernel and low-level services release, then in a a month GNOME/KDE/etc release, then userland applications, then distributions. I have no idea what the right staggering time would be (might be 1 year+ between kernel and distribution), but this would give time for applications to ensure compatibility with the latest desktop environments and then time for distributions to include the latest (stable) versions of these applications.

  222. mah-kittehz Says:

    this replaces my other comment.
    * devs want 6-month releases, are OK with instability, and do bugfixes.
    *businesses only want to upgrade every 1.5-3 years, depending on difficutly, aren’t OK with any instability, and don’t develop.

    Therefore, you want a release every 6 months, and a stable release every couple years (I would go with 1.5 aligned with Debian). The 18 months could be used for big reworkings, but with 2 releases during it to check features and get feedback (E.g. 10.10 is an LTS [supported for 20 months] , 11.04 is an alpha, 10.10 is beta, and 11.04 is an LTS). This might be different for servers, which I don’t know much about.

    This could be implemented by calling them “alpha”, “beta”, and “LTS”, and setting the update manager back to only show LTS’s by default. Optionally, there could be a 10.09 pre-LTS RC that would be mostly finished and give devs time to update applications and do bugfixes.

  223. Mark Shuttleworth: Meta-cycles: 2-3 year major cycles for free software? | Mohamed Zaian Says:

    […] Meta-cycles: 2-3 year major cycles for free software? […]

  224. WermRolent Says:

    Что давно страничка не обновляется =(

  225. WO Says:

    Business world – needs 3year minimum cycle. (many in smb field will attest)
    Use 3-year support; release every 2 years; with one year overlap on support in order to give a steady migration path.

    The unpredictabiliy of Redmond is opening a door for opensource.
    Learn lesson from them (even though they didn’t quite learn), if you make a flop distro, and can’t correct quickly, make last stable system extend active support and actively promote old system.

    If something is new and better, make short release 3-6 month cycle for the cutting edge crew.

    Mark, contact me if you need a Mensa level thinker with top sales and marketing skills. :)

  226. Raphael D. Osborn Says:

    One year cycle its good. No more.

  227. John S Says:

    Ubuntu’s “Fast Cycle” has been a powerful mechanism to improve all of Linux.

    Look to Lean and Agile Manufacturing fundamentals. You want as short of development cycles as possible and the ability to quickly change over from the old to the new. So far Ubuntu has been good at this.

    Development pace:

    Ubuntu’s fast cycle pulls along the pace of development of not just the OS but also the cadence of other projects like Open Office, Firefox, etc. I’m sure you’ve talked with the leaders of those projects as to folding in their latest release (that they might have delayed a bit otherwise). Note that carried to the other extreme with ‘rolling releases’ makes it too hard for people (when do I jump on that moving train? Is this coal car good or do I think I see a sleeper car down there?…).

    Forecasting (fancy “Guessing”):

    The biggest problem for Long Product Cycles is they create a need to forecast further into the future. You have to guess not only the features that people want but what hardware will be available.

    If you normally develop an OS in 5-7 years you get where Vista got stuck. Microsoft assumed Moore’s law continued and people would already have CPUs and Ram more than capable. When the actual launch approached the CPUs had to go to multi-core monsters and have more than twice the typical Ram install “just for the OS”. Corporations would have to wholesale upgrade at massive cost.

    Apple releases in 2-3 year cycles, but they also run on their own hardware and have all the special drivers they need, and don’t try to run on older equipment. However, they still have to guess (but only half as much as Microsoft does), and they don’t cater to the industrial commodity hardware market.

    Ubuntu can look six months out and actually ask the hardware companies “what are you building this year?” and match them. So no guessing. How powerful is that?

    Marketing Message:

    Ubuntu should publish/market the fact it is ‘newer’ than either competing option out there. If you want to be ‘bleeding edge’ then use the latest Ubuntu, or go with a choice of guessing…

    “New & Improved” and “Free” are the most powerful marketing messages used. Ubuntu needs to work the N&I angle.

    However, rigid LTS windows should be communicated to end users so they can plan.

    Conclusion – The optimal cycle would be:

    -1 per year updates. With April launch windows (it’s seemed the April Ubuntu’s have been more successful – holidays must help). Six month cycles do create a ‘cycle-skipper’ attitude, and is more costly for the OS organization workload.

    -LTS @ 3 years with a +1 year for security updates (overlap old & new 1 year). Three years is good because hardware gets depreciated (in the US anyway) over a three year cycle. So this is a natural corporate hardware refresh cycle. Isn’t Debian on an 18 month cycle? This can match their rhythm. This needs to be well communicated so companies can anticipate planning horizons.

    -impromptu security patch, or revised package updates as necessary (to reduce major updates pulling on servers if you’re installing a fresh copy later than say six months). Like 8.04.02 CD.

    Whatever the end choice make sure to keep a fast pace.

    John S
    (Automotive, Computer, Product, & Manufacturing Engineering and Consulting)

  228. Dean Loros Says:

    I STILL am all for the 6 month minor & 2 year major release cycle–I would also like to see a rolling release that would “underpin” all of it–“feature freeze” the rolling release at 4 months in & clean it up–take 2 months to do that & you have the 6 month release–meanwhile you still have the rolling release moving forward in the background–that would give you a lead on the next release–you have more chances to get more testing with kernels & bleeding edge software.

    As for the LTS–take the 3rd freeze release & polish it for 6 months—really wring the bugs out & double-check the stability—It would have fallen back 6 months from the minor release by that time, but the two are different target markets after all..

    I see quite a bit of support in the community for a rolling release–you would not want for eager alpha users (I am one) & we could make faster—better progress (in my opinion) with a 3-track system……

  229. Jack Says:

    Here’s how a commercial product might structure a meta-cycle:

    16.04: Innovative software/feature focus! Pack every new Good Idea into the OS that’s available.

    16.10: Software/feature bugfix and intense focus on fixing of one upstream Major App Barrier to User-Friendly Desktop Linux

    17.04: Hardware compatibility focus! New FS’s, new kernel, exhaustive driver support, and focus on streamlining and speed of the OS.

    17.10: Focus on fixing any remaining serious bugs, making last three versions work well together, perfecting Major Barrier into a commercial-grade product. LTS version

    As it is, though… I don’t think you’re able to direct people along these lines to the degree that a commercial product can. I think the best we can do is approximately what we’ve been doing, because most volunteers pick an app and stick with it rather than focussing their efforts where you decide.

  230. candtalan Says:

    I think the current LTS cycle is a good way to offer a long run of trouble free (and excitement free) use.

    I am in contact with a lot of newcomers from Windows and I offer them LTS, with the exception of cases when they say they have newer hardware, in which case I offer the latest version, to give the best chance of drivers.

    The LTS interim images such as 8.04.2 are an excellent way of consolidating LTS benefits for newcomers because the latest drivers and fixes are incorporated into a live CD and first install – frequently a crucial rite of passage for a newcomer.

    Although I am not a developer, I find the 6 month release cycle exciting and always run the latest release in addition to the LTS daily workhorse. I like the energy that the 6 month cycle encourages.

    If there are weaknesses in a release, it is easier to live with knowing that the LTS version is working well and stable. I think an unfortunate exception might have been the introduction of pulseaudio in 8.04 LTS and 8.10, both gave me some problems until later patches presumably arrived, and helped, not sure of details though.

    The LTS interim images (8.04.2) can be a great help in such cases for newcomers.

    Major changes: I think these can be worked in pretty well ad hoc, but please avoid LTS versions containing anything flakey or not well proven.

    And – thanks!

    similar content as this has been labelled here as possible spam, do not know why, unless my name triggered a filter. I now use a screen name

  231. ray klassen Says:

    I don’t know about every release cycle, but Jaunty came way too early. I have now re-downgraded 3 of 4 home computers to intrepid. So many things just didn’t work…

  232. El adiós a Ubuntu 6.06 LTS (Desktop) [Editada] | MuyLinux Says:

    […] podría ser Ubuntu 10.04 (como bien apunta Walter en un comentario, indicando que Shuttleworth considera retrasar la LTS a la versión 10.10). Esa futura edición no tiene aún nombre clave, pero también podría ser muy relevante por esas […]

  233. jose Says:

    Wow, it has been three months since last update. Seems like your girlfriend kipnapped you . 😀

  234. John Duperon Says:

    Hi Mark,

    What are needed are stable API’s. Think of buying a game for Linux. People have said that no one will buy a game for Linux because the market is too small or Linux people don’t buy games. That’s BS. People won’t buy them because they are afraid that with the next release, their game won’t work. Or they’ll buy it and it won’t work on their current release. Linux needs the equivalent of MS Direct X for the entire user experience. This will shield users from their upper level software not working when the lower level software is massively changed in your meta release cycle. The call that says “Open a window” will still open a window, but likely using completely refactored code. Such a layer of abstraction would also make all apps work in both Gnome and KDE.

    My 2 cents.


  235. vhael Says:

    a cycle of 3 years is better for me because it gripped more factual, and should insert much more novelty to make speak about her

  236. wanda Says:

    LTS 3 year = fine.
    Releases = 1 year = fine.
    greeting Wanda.

  237. Georgio Says:

    Python, GNOME, KDE and Debian are all important. But which of them is most important for Ubuntu?


  238. philsf Says:


    I posted a draft idea in ubuntu-devel-discuss [1], but unfortunately it didn’t drew the attention I expected, and I’m not sure I should repost it ubuntu-devel. I believe my idea expands on your meta-cycle idea, while providing some additional side benefits.

    I propose that the whole 6-month cycle be redesigned so that binary compatibility is sustained between non-LTS releases, and the last LTS release. This would provide many benefits (outlined in the message linked above, and in the blog post [2])

    -reduces maintenance resources
    -mirror storage usage
    -smoothen dist-upgrades and offer third party developers a more stable environment
    -still gives users the latest Gnome (and KDE), Mozilla, etc.

    I’d like to hear your comments on this. Best regards.


  239. Gareth McCumskey Says:

    My take on releases is simple. The 6 month schedules should only be used for enhancements and bug fixes on existing packages within a distribution. New features should follow a longer release cycle as well as new versions for existing features (such as the upgrade to a new version of X in Jaunty for example), possibly a year. In this case you can have early adopters and beta testers install these newer versions and newer features but the people doing a dist-upgrade will only be getting the new versions and features that have been tested and fixed for over a year, giving more maturity.

    The simple reason I suggest this is because Ubuntu is starting to become infamous for dist-upgrade breaking things. People using Ubuntu as their primary OS, and I mean specifically the average Joe user who doesn’t want to hassle getting things working, wants a seemless upgrade process without worrying about fixing things after, or at least to reduce this to a minimum.

    Having fixes to existing features released every 6 months and allowing more potentially dangerous packages etc a year to stew and be tested is a good way to help ensure that when people do eventually upgrade, the drivers are ready, everything has been tested as thoroughly as possible etc.

    One other bone of contention I have is how Ubuntu seems to keep back upgrades to packages that have very little to do with Ubuntu itself. Things like Firefox not being available to upgrade to 3.5 until Karmic is released, graphics drivers, etc. Those two specifically require the user to add additional repositories to get them, if they can find them that is.

  240. Fábio from Brazil Says:

    do not compare ubuntu with fedora, suse and windows and mac. i switched to ubuntu because i saw improvements all this years with this actual cycle( 6 months), i am an ubuntu user since 4.10. Why ?, ubuntu gives me a nice usability with gnome, the system is more stable , more quick and it’s well finished comparing with all linux distribuitions. about 300 new features thing in mac or windows vista, why do i need a feature that do nothing? why do i need 250 features that do nothing useful, that consumes more ram and time processing, that it makes a dual core processor with 2gb of ram run like an obsolete 486. vista has a lot of features that xp don’t. so why xp still more popular than vista? it’s easy, it’s because works, runs well and people want to use nice apps and also want their hardware works well!! fedora as a list of new features, but im my opinion this point do not make fedora 11 better tha actual ubuntu 9.04. fedora is the bloatest linux distribuition for a long time, every linux users know that. fedora is folloewd by novell ans suse. sometimes a ask myself, why do i want to use suse if this distribuitions runs same like vista, the finished product is too bad, too heavy, too bloated is too a lot of things that will keep end-users prefering using windows. canonical have to keep the focus in end-users, keeping the things easy for new linux users who come from mac os-z and windows.

  241. Fábio from Brazil Says:

    i have finished kubuntu 9.04 testing and dude this new kde4 usability was terrible. comparing kde4 with kde3 is same comparing xp and vista. kde4 is only beautiful but i don’t want to use a linux distribution only by beauty. gnome and xfce give more usability for the end users, are more stable and with little efforts can also be pretty. i did a lot of ubuntu 8.04 instalations here in rio de janeiro, for people over age 50’s that never used a computer before. why i have choosed ubuntu. to simple answer. its because simple, stable, more secure than windows, has a nice gfraphical interface, has focus on usability and the most important it’s easy for the people who will use the system ! without blue screens, without boot files corrupted that make the system not boot, without viruses, trojans and spyware. dont forget that these peolpe never used a pc before, they don’t need complex programs, don’t need to know complex terms. they only need something easy and simple to use with no risks. ubuntu goals it!

    sorry about my english!

  242. Mufaro Says:

    Mark: are these truly your words and thoughts? Why? because I am by no means technically astute and so i seek comfort in knowing that my learning is from an expert – someone who has had his “hands dirty”. Not to say that I take all you say for face value – the comments also add color.

  243. irritator Says:

    Where is the new look for Ubuntu as promised everytime ? Could you please post it here

  244. Nikolai Says:

    So how does this change things ?

  245. Tom Says:

    Now that Debian has adopted time based freezes will Ubuntu LTS ship the same versions as Debian stable? I would love to see a really RC bug free LTS release.

    PS. You need to blog more.

  246. Asi es linux (a parte de libre, claro est Says:

    […] 4.0 y Debian 5.0)… La idea del fundador de Ubuntu queda expuesta en el siguiente art

  247. Debian-ски новини « Wiseacre`s blog Says:

    […] решението има нещо общо със статията на  Mark Shttleworth „Meta-cycles: 2-3 year major cycles for free software?“ от 17 […]

  248. Sanjay V Says:

    Well, I always thought that a 1 year cycle would be best for Ubuntu since that would give it a lot more time to do something new from the last release. But since this topic deals with ‘meta’ releases, I’d say that it would be better if Ubuntu stuck to its 2 year LTS promise since if a package like Gnome decided to release new software and it breaks the LTS at the last moment, it would be a huge pain. Its best to go with tried and tested software at that time, in order to have a stable system. JMO

  249. Hilton Gibson Says:

    About cycle-naming. I would like to hear someone say the following:
    “Ubuntu releases a development version every six months leading up to a production release every two years.”
    This comment makes a lot of common sense to a person-in-the-street.

  250. Carlos Says:

    Hi Mark,

    As always your posts are very interesting and easy to read. This one is a very interesting topic as I for one feel is a key aspect for the Linux world in general. Why not have both short and long cycles with the releases?
    One aspect that I believe turns away many people in Linux is that its changing too rapidly. While this is a factor of excitement for those who are already in the community, for outsiders it can be too much to dealt with.
    Imagine John who gets his first Ubuntu box, with state of the art software and all, but three weeks later the new KDE, a month later is OpenOffice, then Gnome release a new patch, etc. For someone in the beggining of their learning curve this would be overwhelming.
    As far as releases go, I believe Microsoft has got it right. Release a new Windows with a few years apart (they should respect deadlines though!), and then release Service Packs. This model I feel makes the changes more gradual and is easily adopted to any distribution.
    Ubuntu’s 6 month releases and LTS could be a parallel to that. Main release every 3-4 years, and important patches would come out every 6 months. At least users know that until the next LTS comes out, their box is still up-to-date and the Linux world won’t turn upside down!

    Hope I was able to explain myself well enough.
    Looking forward to the next post!

  251. Secrets Says:

    Some distros have rolling releases. Have you thought about what this can bring to users?

  252. yuanchuang Says:

    a cycle of 3 years is better for me because it gripped more factual, and should insert much more novelty to make speak about her

  253. Trod Kine Says:

    What happened with this blog? F5 my friend, F5…

  254. Richard Says:

    I think the answer to the solution is simple.

    6-month cycles only have support until the next 6-month release and are very close to bleading edge as they are now. Regular users are recommended to stay with LTS versions that have proper length support. Then make normal LTS releases support for 1.5 or 2 years and keep server lts support longer.

    This way you take advantage of both worlds fast development but have time to fine tune the new features for 1.5 year release to the consumer at which point they are prompted to upgrade to the newest LTS version.

  255. TorturedUtopian Says:

    All this thread is very enlightening.

    To me (average user), there are 2 issues that keep long term releases from being accepted :

    1) Drivers ! Recent hardware takes some time to be supported properly. What if I have to wait 2 more years for a graphics board to work properly ?

    2) Contrary to closed-source OSes, it’s difficult to tell the OS apart from the software. The ideal would be to have “core components” that remain the same (with bugfixes) a long time, while apps are updated more regularly (because new features may be needed, because of performance improvements…). However, every piece of linux software is more or less dependant on the other layers.

    However, short term released are not ideal either, because : drivers sometimes get broken, some broken feature are added etc.

    So, would it be possible to have a stable core system, up to date drivers, and not-too-old stable apps ?

  256. Alistair Munro Says:

    Can I pitch in and provoke a little discussion from a completely different perspective? The main point I want to make is to question whether synchronisation of release cycles between major distros and projects can be assumed to be a good idea. The only advantage as far as I can see is that it would make the development calendar easier to understand an predict. However, I don’t think it follows that a simple calendar would be much help to deliver a better OS.

    I have a concept in my mind that at it’s most simple, could be seen as a “seasonal development calendar” for Linux as a whole. Say for example we do tie Ubuntu releases to Debian releases. Firstly, would the Ubuntu Devs be concentrating on their release targets so hard, they lose focus on Upstream events at Debian? Then Debian and Ubuntu have to compete for the small limited media space available, and folk wishing to try out the new releases are hit with the choice at the same time. It just seems like everybody on the same side is set up to trip over each other to get to the same objective. Why not deliberately off-set or stagger releases, so that they are created and distrobuted evenly throughout the year? So for example, Debian put out their major 18monthly release in January. Ubuntu then have three months to anyalyse and incorporate those advances and still release to and the big Linux news in March isn’t trumped by a big Debian release? In turn the Mint and Crunchbang folk would then have a couple of months to get their major version updates highly polished and so on downstream.

  257. e-node blog » La prochaine LTS décalée de 6 mois ? Says:

    […] Shuttleworth a récement évoqué sur son blog la question des cycles de développement de la distribution […]

  258. Nick Says:

    Comments are tl;dr so forgive me if someone has already offered this suggestion. What about a mixing in a year long cycle between every few 6 month cycles? For example:

    6 month
    6 month
    12 month
    6 month
    6 month
    12 month

    This way you are never more than a year away from the start of a long cycle and short term goals can be accomplished before the start of the next long cycle. We really don’t need symmetry in our release patterns – what we need is to eliminate half baked ideas making it into short term releases.

    Asymmetrical release cycles FTW!

  259. Shane Rice Says:

    I think both cycles are good. I use both. I use the short cycle on my computer, but the long cycle on my Wife’s and kid’s computer. It is easier for me to not have to mess around with installing/upgrading every 6mo for them. They are running and using Hardy. I have noticed that they are (for me) very outdated, and I really like the new improvements and miss them when I sit down at their computer. That being said, I would say a 2 year major cycle as a desktop user would be better. On the other hand I could see where a major company, or any business for that matter would only want to update every 3 years, it is work and time, especially when dealing with more than one machine.


  260. jimbob Says:

    You haven’t blogged or since April 2009!

  261. Nick Says:

    Ubuntu 9.04 is looking to be a pretty boring release. Please forgive me for saying this – but this is the problem when you force yourself to release every 6 months. I like the idea of regular releases, but maybe we should remove the symmetry from the release schedule and add a longer development cycle after every couple of short ones. For example:

    6 month
    6 month
    12 month
    6 month
    6 month
    12 month

    This way you can upgrade upstream software and fix bugs in the shorter cycles and have time to fully bake in new features in the longer cycles. You would never be more than 1 year away from the start of the longer cycle and would never get out of date thanks to the short cycles.

  262. scouser73 Says:

    I always look forward to a new release of Ubuntu but just recently I’ve been inclined to look more on updates in software like Thunderbird, Openoffice & updates in kernels. Obviously there is no need to switch to the latest offering, but by having the six month release cycle it feels, in my opinion that there is a need to update the current version.

    For me personally I would feel the benefit more if a longer cycle of releases were done, thus making it feel as if the user is actually experiencing the latest and greatest offering from the developers.

  263. Mark Shuttleworth – El hombre detrás de Ubuntu « Blog del Ing. Linux Says:

    […] inactivo desde abril de este año (2009), la ultima entrada que publicó estaba relacionada a los Meta-ciclos de 2-3 años para el software libre refiriéndose a las bondades de tener ciclos de liberaciones regulares de nuevas versiones (en […]

  264. Giuseppe Says:

    Hi Mark,
    not sure you will even see this, but here goes:

    I am a total newb on Ubuntu. Not because I didn’t try to get it on my laptop before. I did. I also like to think I am not too stupid or computer illiterate when compared to the great masses of computer users, neverthless installing Ubuntu on my own in a way that “just worked” was essentially too time-consuming and “difficult” for that reason.

    Fast forward to a couple of months ago. Despite Dell apparently reducing what is available with Ubuntu pre-installed to just one (tiny) notebook I bought it. Essentially because I am so sick of bug number one (Windows).
    Well…how can I describe it…

    It was like a revelation of spiritual significance. Everything just WORKS.
    My God…I thought…this is how computers are supposed to be. We have been lied to and enslaved for too long.
    It was like eating the right coloured pill in the Matrix but waking up to a much better world you only suspected existed in dreams.

    EVEN SO… I still don’t have the time to make Ubuntu work on my currently Windows laptops…soon I will be unemployed (by choice) and I will then make the time, however what has been driven home to me is that there must be millions of people like me out there that would switch to ubuntu in an instant if it were just idiot-proof-easy.

    On this note I have given it some serious thought and given my soon to be found new indipendence have been constantly thinking…man…why doesn’t someone organise a factory to just produce ubuntu-pre-installed laptops for the masses.
    I still don’t get it. And I still think it would be relatively easy to set up and very profitable.
    No one seems interested to do it or maybe they don’t have the money.

    I am willing to step up. If you can help fund the startup (and retain major interest/control/shares obviously) I am willing to give of my time to make it work. I don’t think my relative ignorance of the technical aspect is necessarily very relevant at this stage for this kind of project, but I do have a clear idea of how to go about it and I am willing to devote my time free of charge until it works (at which point I’d be wanting some money/shares/gold ingots/whatever) if you are willing to hear me out on this please let me know. I will also try to contact you again more formally in a few months with a proper proposal with some clearly defined points.

    If however you are for some reason against even looking at this please just let me know now so I don’t invest too much time in it over the next couple of months.


  265. Waldir Says:

    Hey, Mark, I miss your posts! Get you *** back here! ;-P

  266. mike Says:

    Hello Mark,

    I’m a new computer/Gnu/linux/Ubuntu user with no any other OS experience; (Newbie across the board). I’ve chosen to use Ubuntu 8.04 for it’s stability and longevity. This is what a Newbie needs, to begin to learn about OS’s. Not something that is changing so fast that it overwhelms with a too high learning curve. Since Freeware; Open Source; and GNu/Linux are aiming their sites at the masses; In making your decisions on how to evolve releases, please keep in mind the needs of the clients you wish to serve.

    From a Newbie’s perspective; having a lengthy cycle of LTS releases is imperative, to facilitate and allow the accumulation of the knowledge base needed, to be able to eventually, adapt to and contribute in, the faster changing technology of short term releases with their inevitable challenges.

  267. Visión radical de Shuttleworth sobre Ubuntu Linux « Blog del Ing. Linux Says:

    […] desarrollo de Linux. Mark ha discutido con la comunidad esta visión ampliamente en a través de su blog. Es una visión muy diferente de cómo se hacen las cosas ahora. Según Mark, el estado actual esta […]

  268. salemboot Says:

    You’ve got a decision to make. Will you release with broken packages?

    I’m sure if you were making swords the obvious answer would be no.

    But the computer is a tool and that tool may as well be a hilt with no blade when missing an operating system.

    Linux distributions are more of a range in dull blades.

    Carbon: Custom Patches
    Serrated: Ultimate Edition
    Sharp: Mint
    Dull: Ubuntu
    Blunt: Debian

    The longer the blacksmith folds the steel the stronger the blade but there is a limit.
    Find that magic number for the blade you’re trying to make.

    So you can’t expect Xorg Katanas to take the same number of folds as your Claymore Ubuntu.

    A kernel Rapier may 6 folds a release make but Mesa Scimitars have no folds at all.


  269. Ashamed Ubuntu-guy Says:

    Urgent area that really needs co-operation:

    I sure hope that in forthcoming 2-3 years Ubuntu would try to catch Windows in ability to use voice too as input / output method. User with just mouce and keybad is much slower comparet to just say “open firefox” … “browse” … “start to read” like you can do with Windows (speech regognition and Narrator).

    I’m very embarrassed as Ubuntu-guy compared to my Windows-girlfriend while she can use her voice with her computer… and even to dictate emails and these comments too, without keypad.

    We really should have that too, don’t you think? And that really needs co-operation to make it work with all apps.

  270. Tom Says:

    You should be aware of this. I think that the life blood of the linux community is it’s developers and it is important to keep them onside.

  271. noiv Says:

    A three years cycle to do what? Who can imagine the iphone 2012 today? Will computers still have keyboards and mices? Or is everybody sending eVideo, eAudio to friends using 3D gesture input and stays in contact by video twitter.

    Facebook is then an always on realtime app running on my mobile displayed by a pico beamer – no need for cables, heavy hardware and clumsy human interfaces.

    To plan Ubuntu Mobile I would start now, collaborate with a descent open hardware developer and get it on the market ASAP.

    We are talking about bold moves, right?

  272. Alan Says:

    I havent read all the comments, so apologies if this has been said before; a common thread, from the OP to the responses, appears that the question “how long before releases” is being asked from the point of the developer community. How about from the pov of the user community… e.g. non-technical user sat in office, or better still, the business decision makers who decide what OS their organisation uses, or the hardware manufacturer who decides what OS ships on their products.

    6 month cycles for these peoples = ‘death’ for your release… it means change occurs every 6 months, which is unsupportable in a business environment, asone would need to retrain the support teams every 6months, ideally before the changes go mainstream.

  273. zelrik Says:

    Hmm no more blog posts? Have you been too busy lately Mark?

    I am gonna try ubuntu 9.10 this week end, I hope the Intel drivers are up to par now :).
    Keep up the good work, and kill those nasty bugs and annoying regressions !!

  274. Linux And Friends Says:

    Why doesn’t Ubuntu follow a philosophy of providing a rolling release which does away with a 6 months release cycle and brings continuous upgrades to the end user? I am talking about an Arch Linux style upgradation process.

    Just my two bits.

  275. kikl Says:

    Well, unfortunately, Mark seems to have pretty much given up on posting anything here. Maybe the discussion was not particularly helpful in his desire to improve the coordination of releases among open source developers… Envy among the different distributions – debian, suse, ubuntu – appears to be a major obstacle. Now, I sure wish the relationship with ubuntu’s mother distribution debian could be improved. This seems to be one of the major things one could wish for.

    Since Ubuntu has become such a big player, I think upstream developers shall eventually adapt to ubuntu’s schedule for new releases. Mark should just keep on doing his thing. The residual players will – if they are not willing to compromise – eventually adapt to his release cycle in their own interest. He should not lightly deviate from his release cycle, because everybody else is counting on it. Only major major contributors like debian or gnome should tempt him to deviate from this schedule. Everybody else, upstream developers as well users, could be “pissed” if he doesn’t deliver on schedule. So that would be the price he would have to pay for deviation and it really should be worth the price.

    Final thoughts on karmic: I think you did a wonderful job. Boot-up times as well as responsiveness have been improved considerably. The artwork is improving too, although not as apparently. Nautilus and the displayed folder icons come to mind, nice job, what about the theme colour?. The audio interface. The combined empathy/evolution ikon in the panel. The new software center is really fool proof. Ubunto-one is nicely integrated into the desktop. And everything seems to be running smoothly without any major problems – o.k. minor glitches…. If you keep on improving at this pace, well then OS-X could be in your reach pretty soon;-) I adore Ubuntu! My partner – a staunch apple supporter – is becoming frustrated by your improvements. Upstream has delivered too. Both open office word and evince have resolved bugs I reported – these are two applications I use a lot….

    Well, I would like to make a few recommendations for the next release.

    1. Gnome 3.0

    Don’t integrate the next major gnome update in the next long-term release. I fear that the same problems will arise as in KDE. I have looked at the new interface. It is nice, but doesn’ knock me over. I hear that the new gnome interface (zeitgeist?) may not support compiz. Please do not sacrifice all the features compiz users have grown used to for – well this bites – moving around a few buttons on the interface.

    2. Package converter:

    Integrate the package converter into your next release, at least integrate it into the repositories. The package converter lets you convert rpm into deb packages. It’s a very simple graphical user interface and you no longer need to use alien.

    3. Gnome-do:

    I love gnome do, It’s magic for anybody who uses his computer a lot. Please take a close look at it and let it be part of your ubuntu repository. It is part of my desktop and I am extremely fond of it. It can’t be described in few words other than magic.

    If you have any problems or concerns with regard to intellectual property matters in Germany, please contact me. It’s my profession and I would be very glad to help as a way of contributing to Ubuntu.



  276. Demetris Says:

    I liked the idea to cooperate with debian release shedule and postpone the lts for 10.10 or X.X 😉 Also i would like to have a different versioning system Lets say
    Lts will be 10.10 next version should be 10.50 10.60 10.70 next lts would be 11.xx
    So short term release would be an update to lts until a new lts version comes out no need to go from x.4 to x.10 and back to xi.4.
    Also with every new version of ubuntu i find it difficult to discover the differences because they are so close each other. We need every major version update to show that it is a version update and feel and act like one. Major steps need to be taken from lts to next lts to show the direction of the ubuntu distro, things that show progress and a meaningful new release.
    Also would be great to have a theming update as the ubuntu desktop looks like is stuck to brownage!
    A more pleasant bright and colorful theme will be a more than welcome.

  277. velo electrique Says:

    agree with Jon Rutherford

    “In the US, one form of advertising we often see is “New and completely redesigned for 2009!” OK, GM or whoever you are, if your last car was as perfect and wonderful as you said it was, why did you have to scrap the design and start all over? I think this is relevant to software — and software advertising — as well.”

  278. jared Says:

    My Thoughts on Time Based Major Linux Releases…

    Like all organizations, it’s important to properly manage expectations.
    Mark Shuttleworth asked awhile back about …

  279. Jared Says:

    Like all organizations, it’s important to properly manage expectations.

    Personally, one key issue here is managing expectations. Ubuntu’s past releases have created for me the following expectations:

    * Even numbered first iteration releases are Long Term Support releases. (6.06, 8.04)
    * Even numbered second iterations are cleaned and more stable Even numbered first iterations (but are not LTS). (6.10, 8.10)
    * Odd numbered releases are useable playgrounds that are used to collect information for the next LTS. (7.04, 9.04)
    * Odd numbered second iteration releases are cleaned and more stable Odd numbered first iterations. (7.10, 9.10)

    Wether or not the above is true, for some reason it’s the message I heard since starting with Ubuntu 5.04. It’s now what I expect from Ubuntu releases.

    If Ubuntu decides to implement a new release cycle it should have a clear understanding of current customer expectations. Otherwise it risks putting serious strain on customer relationships with Ubuntu. I know I’ve stopped being loyal to company brands because of failed expectations. It’s totally fine to change things up, but it needs to be well communicated to users.

  280. pcastet Says:

    I do believe that the only way to gain a noticeable market share in major corporations for Ubuntu distros is to support LTS for way longer than 3 or even 5 years, something like 8 to 10 years seems to me a minimum.
    Most IT Directors want to know that they won’t be “forced” by some Linux geeks 😉 to migrate their tenth, or hundredth, or thousands computer systems thx to a lack of support. They want to keep the decision for themselves or their Executive Boards. They’re ready to pay big bucks for it. They don’t really give a damn’ about free software or proprietary software. They want software which suits their needs on the long run, which they trust would still be there roaming in a long time to protect their investments and their careers. And with a clear way to get support from a well established company they entirely trust.
    Red Hat rules at this stage amongst . Canonical and its associated foundation is clearly mandatory to allow Ubuntu distros to enter big corporation’s servers rooms and big data centers. Elsewhere they’ll choose another OS for their servers as they won’t be confident at all as they can’t contract anything with anyone. For desktops the path seems to me much longer for Ubuntu vs Windows than for servers rooms where “only” a few people, often technically aware, to be convinced to switch from Windows or big Un*x brands. And “only” servers stuff to be migrated. Firms have countless MsOffice or windows-only docs with macros they will never ever want to have trouble with as it runs their businesses and are used by everyone around them. Firms don’t want to alienate their staff which what will mostly happen for such moves from Ms to Linux desktops as usually people resist changes, even for the better :-).
    Mammoth corporations are probably the most difficult market to enter for Ubuntu, but I believe that it is necessary to succeed in entering them as they then will ask their suppliers to deliver Ubuntu compatible software. Imagine … :-)
    Another important thing is for Ubuntu is to deliver a clear, easy and safe way to migrate servers from LTS version xy to next one on an industrial scale. 10 servers can me migrated one per one. Not 5000, too expensive.
    I know my post is not very free-software-minded but it is real-world-minded. I read a post a few days ago telling that open-source software represents 2.5 billions lines of code. I thought : “whao !”. But it also told that nowadays cobol software running in firms, written since the 70’s, represents 200 billion lines of code, increased by 5 another billions every year … That’s real world of IT. It needs to be confident about how long an OS they plan to use will be supported and who will sign the contract. And actual 3 to 5 years of Ubuntu LTS is not enough for most of them as they often run systems 8, 10 years or more. I see that all year long in my job, brand new software, sometimes entirely built upon free-software, working with some other old un*x box running since 1990 for some stuff corporate bosses don’t want to reinvest a single dollar but don’t want to retire either.

  281. yman Says:

    I really want this idea to be heard by Canonical, since it’s a business plan which, if executed, will make my life a whole lot easier. So here (

    A. Switch concepts from “Software Repositories” to “Online Product Inventories” (OPI). OPI can contain products of all types, including software, music, or grocery items.

    B. Create an online payment service called “Ubuntu Shopper Partner” (USP), which the online shopper can use to purchase products from OPI. This service will integrate with the package management software on the user’s PC so that stuff like product keys will be handled in a manner transparent to the user. USP will make money for Canonical through fees.

    C. There will be a program offering to include OPI in default Ubuntu installations in return for monetary compensation. All products in such OPI must be fully compatible with the Ubuntu release in which they are included.

    D. This obviously doesn’t come to exclude Free Software, only to add commercial options as well.

  282. Linda Says:

    For me,I do not like Linux. It is difficult to me.

  283. Gary Says:

    Hi Mark,

    I recently made the switch from the world of windows to Linux. Actually, I installed Ubuntu 9.10. Nice release, thank you! I just now stumbled across your blog, and this thread. Sorry for the belated post.

    I would suggest an 18 month to Milestone / 18 month to LTS release cycle. These would be broken up into 6 month releases.
    1) The Milestone: is the stable desktop/workstation type release. These are supported for the duration of the 18 months between Milestone, and LTS. This is also the staging area for the ‘upcoming’ major API type upgrades/updates.
    1.a) Milestone +1 would be the time for a weighted % of major updates.
    1.b) Milestone +2 would be the time for a weighted % of stabilization, but still include some new but somewhat less risky updates.

    The third post Milestone release of course would be the LTS. The LTS of course would be heavily weighted % wise to Polish Polish Polish and more Polish.
    1.c) LTS: This release is about stable API’s, stable package updates, and a development environment that fosters intermediate to long term ‘growth’ for its intended audiences. It’s security, and major packages should be maintained throughout its life of 3 years.

    Happy Computing,

  284. kristiang Says:

    From the final user perspective I and my friends dislike the 6 month cycle because we need to upgrade the system every 6 month and final users don’t like to change things every 6 month. I believe that a year cycle is a nice period to change a system – like Mandriva we can have Ubuntu 2010, 2011, 2012… is sufficient for final users. For a ‘long term service’, I believe that 3 years is nice, for sample today I’m using Ubuntu 8.04 LTS because I don’t have necessity to change things in my production computer every 6 months… Take these consideration on mind!

  285. Back to the Future, the Future of Software « The Unctuous Rants of Leif Andersen Says:

    […] “Meta-cycles: 2-3 year major cycles for free software?” Mark Shuttleworth: here be dragons. 17 April 2009. 17 April 2009. <;. […]

  286. pollycoke :) » Aaron Seigo sui meta-cicli auspicati da Shuttleworth Says:

    […] read Mark Shuttleworth’s blog entry about meta-cycles this evening and was taken back in my mind to an entry I wrote in September of 2007 about […]

  287. Yarko Says:

    “Long or Short” — That seems to me to not be the central question, but artifacts of something else.

    Of course, the benefits of short cycles is that you see things work (or not work, so you can correct them). I have always been in favor of 15 minute (max) codking cycles, but I would not recommend a 15 minute release cycle.

    So, what is the process that is in play driving long vs. short?

    Big change == big unknowns;
    Small change == predictable (stable) results;

    How (naturally) do those two interact?

    You will recall any college course you had as a prerequisite – there had to be some overlap for you to bootstrap to the next level. Can you do short cycles to accomplish big changes? (Yes, or course – but what will that natural process look like?).

    Let me get back to the 15 minute coding cycle for a minute (or even, if you will, test-driven coding):

    If I know what I want to do, I (lets say) write a failing test. The process forces me to work out little details that simple specification might miss. That is, it’s a discovery process.

    How do I build a group of 15 minute cycles into a short term (usable, complete feature) release?
    I discover the shape of the test; I make parts of the test (incrementally) succeed; I may discover things along the way that the feature hadn’t considered about interaction; I maybe go update a collaborating part of the system with the new knowledge – that is to say, I work on the component, and on the interface.

    Now, let me talk about the big change: I layout what new I want. I work out the big pieces of the problem. Things I don’t know how to do, I prototype (quickly) – that is, I instigate a discovery phase to feed the abstraction level I am shaping (this way I avoid “analysis paralysis”). Once the new function is worked out, I work out how it integrates, fits into something existing (system interface). Maybe I identify new technology that would be desireable (think of the first CD recorder, how that process came about). I use a “second choice” technology until then. I make tradeoffs. Once I have the big-system plumbing (interfaces and technologies) chosen, I might stub out a prototype for those interfaces (instead of making some connection or calculation for the user, I will print “this will make a connection”, etc.).

    I structure my part of the system (that which I have control over), and I repeat the processes of structure & discovery, and stubing and functionality until there is something useful.

    You see – with goals of discovery, the issue is not one of long term vs. short term – it’s one of integrating the two, and when (and to whom) you expose the short term at the state you’ve achieved.

    If you have no overriding plan, no big bang happens. But, if you have an overriding plan, discover (or change of available technology) will modify your big plan – maybe a little, maybe a lot.

    But the big unifying factor of BOTH events (to use KDE and Gnome examples) is that they fit into some plan; some part of a big new plan will not be ready for prime time; when they are, they will go thru the phase of discovery inevitable when exposed to an ever larger user base. This is where incremental an big-plan converge and overlap. I would argue, this is the new (higher abstraction) ever-ongoing incremental: it’s nothing new, it’s just a higher level view of the same things scaled differently and integrated differently.

    There is a process for identifying the important things at the higher level of abstraction (call it Architecture, but it is more than that, and architectural rules alone don’t cover it). In fact, I think of 3 different layers, or kinds of architecture in designing systems.

    The process is a complete parallel to team/social processes; human systems (how they operate) and big system design match well, and in fact must intersect / interact.

    I would be happy to talk more about this, for anyone interested.

    I’ll be at PyCon-2010. See you there.

    – Yarko

  288. Djerba Says:

    Nice to find your Blog :)
    I’m a fan of ubuntu and I really like Ubuntu AppStore !
    And I’m following this Wiki :

    I think this is the proper time to convince Adobe and graphic leaders to target !

    Ubuntu would be a better professional friendly environment and more independent 😉
    Thank you :)