The benefits of a regular release schedule

I have recently read the announcement that Kubuntu 8.04 is NOT going to be an LTS release, thereby deviating from the release schedule of all the other Ubuntu variants. I believe that it would be more beneficial to synchronize the LTS releases between the official Ubuntu variants.

First of all, Ubuntu needs to solidify its public image as much as possible. This is even more important while it has such a small mind-share in the overall technology market. Most computers users have no idea what an LTS release is, and they could be confused by mis-matched numbers. "Why is Ubuntu 8.04 LTS and Kubuntu 8.04 not LTS? Why is Ubuntu 8.10 not LTS and Kubuntu 8.10 is LTS?" Some IT departments might choose to only support LTS releases of Ubuntu. Now they must work with their KDE users who would need to upgrade on a different schedule than their Gnome users.

I understand why Kubuntu wants to delay their LTS release. They have a shiny new version 4.0 that provides many new features, but it is not quite ready to be considered for an LTS release. Historically, the last LTS release (Ubuntu 6.06 LTS, Dapper Drake) included primarily minor changes that focused on stability and polish. For Kubuntu 8.04 to be an LTS release, it would need to stay with KDE 3.5. No major changes should be made during an LTS, which I think everyone agrees upon.

The unfortunate timing of a moving KDE 4.0 release date is a problem that can be corrected. Mark Shuttleworth suggested at the last aKademy conference that KDE should change its release process to a hit a regular schedule. You can view the video of Mark's keynote address on the web. The idea is a simple one: Set a hard date and modify your goals (features) to match that timeline.

This sage advice was not well received, but it should be taken to heart by KDE. I believe that it would tremendously benefit KDE to create a regular and predictable release schedule. See the benefits that this has had for Gnome and Ubuntu. When open source projects have dependencies with each other, a regular release schedule allows them to plan their releases better. For instance, Ubuntu trusts Gnome to hit a stable release on time so Ubuntu provides them more time before freezing changes.

Now consider the negative aspects that an unpredictable release schedule brings. The best example of this is how users left Debian for Ubuntu so that could get an OS that provided regular releases. Another example is how the release of Microsoft Vista slipped multiple times, throwing off the plans of IT departments, software development companies, and computer vendors. A predictable release allows external parties to prepare and plan for the release. If KDE does this, they too will reap the rewards that Ubuntu has seen.


  1. While I agree KDE would benefit from a more regular release schedule, I disagree that IT departments will suffer. Ubuntu users can install kde-base, and a good IT dept can spin a 'custom variant' from server and a couple third-party apps. What I'm saying is Ubuntu+KDE does not Kubuntu make.
    There's more to Kubuntu than just KDElibs/Qt apps. That's a big part of it, but the choices of third-party applications is generally geared more towards customisation and aesthetics in the interface than "one way works well enough for most."

    Kubuntu was originally going to have a KDE4 in the repository, and still be an LTS. Kubuntu is BASED on Ubuntu, but isn't Ubuntu.
    I honestly don't think it's a good idea to have even a 3.5-based desktop be LTS! Why not?
    Well, it's going through some pretty hairy times in the community. how the current bugs are handled, will new features be added... It's absolute MAYHEM!
    ...OK, not MAYHEM, but it's not the kind of environment you want to release something as "Long term Support." Packages likely to be ignored by their own community until their successor is more stable...

    In short, let Kubuntu be Kubuntu.
    Ubuntu can be the stable "just works" version, Kubuntu can be the enthusiast desktop for interface tweakers.

    Kubuntu is fast becoming the "KDE for people who don't like OpenSUSE" distro, and thus it's one of the two main ways people are getting exposed to it. KDE4 would lose a not insignificant 'market' without an alternative to OpenSUSE(some people don't like Novell, after all...) others can't wrap their brains around setting up Fedora, especially since GNOME is standard for that system.

    Let it be. Keep reaching out to KDE developers. Heck, help them reach that goal!
    I'm just learning to program, and I'm hoping I can eventually pick up the KDE4 bindings for Lisp, which have been abandoned. I originally submitted it to a social bookmarking site, with hopes someone would do it, then realised I COULD DO IT! it would just take time and learning.

  2. Actually it was Canonical who decided that Kubuntu won't be an LTS. The Kubuntu developers had no say in it. They were only informed about the final decision.

    And it's not just Kubuntu who won't have this tag - I'm not sure Edubuntu, Xubuntu or other releases will be having an LTS release.

    It may be that Canonical wants Kubuntu to invest more time into KDE4. It could also be that Canonical wants to promote Ubuntu commercially more at the expense of denying the same right to the now "pseudo"-officially supported Kubuntu. Or there may be another reason. Who knows?

    An official statement from a Canonical employee who decided it would clear up the confusion. There are many questions that are popping up:

    Is Canonical throwing Kubuntu into the community-supported-only-not-good-enough-for-businesses waters? Can we make Hardy+1 or +2 an LTS, when KDE4 will be stable enough? Is there going to be an LTS of Kubuntu in the future?

    I can ask someone personally, but I'd prefer to have a public FAQ regarding this decision.

  3. I think it's a really stupid idea. KDE 4 is being heavily rushed. The so called "Release Candidate" is only alpha, or at best, beta quality. I absolutely hate it when point-zero software is released; it makes people go insane. IMO, Kubuntu should be released as an LTS with 3.5. Version 4 shouldn't even be an option yet. I'm sorry, but it just isn't stable and KDE 4 isn't the cure for cancer nor will it solve world hunger. There is nothing wrong with waiting until 8.10 to make a release with KDE 4. If people want KDE 4 sooner than that, then they can use an unofficial repository, but pushing such incomplete software on average, non-technical users is poor decision.

  4. Hmmm. I don't hear about too many 'average non-technical users' using Linux, let alone moving to KDE.
    They're used to the Windows Way. "One way, no choices, we don't care what you want to do," and they're happy to see that they can make the taskbar blue, red, pink whatever. Well, that's all you can do in GNOME, but that's more than they had before.
    I hear more about people that move to KDE from GNOME when they realise what a 'desktop environment' is, that there's a choice, and that KDE gives them more freedom to configure it.
    In that same way, a smaller company is more likely to use the KDE-based release here because it's not the standard release. How many big companies are going to listen to 'that computer guy' when he says "I can make the desktop more *insert feature requested by employees/management* if we use Kubuntu," instead of thinking "It's all Linux, and I keep hearing about Ubuntu, not KUbuntu! *harumph*" and just going with the 'standard' realease? (wow, that's quite the run-on sentence...) I'd reckon not many.

  5. Come on guys! Change the 'mind set' and establish a goal based on 'standards' and not one based on 'time.' If you establish a standards based goal, you are going to end up with a better product, ready for release, and that 'works.' When you develop on a 'time based' standard, you are forcing yourself to (most likely) release a product that may not be ready for prime time.

    A lot of people who have never used Linux are coming over from the Windows community. If their first experience with a release is 'less than favorable,' what have you accomplished?

    A Quality based standard should be preferred to a Time based standard.

  6. What Anonymous said is not "untrue", but...

    The write is talking about a time-release schedule equal to the one Gnome uses. This means that at the time of the freeze only the new stuff is included that is stable enough, the other parts will wait until the next freeze.

    I also agree that a gnome-like release schedule is the best for all. And please, do not compare it to the Ms release schedule. If those would be our standards in Linux... (nevermind)

  7. I think there is worth in both approaches. I think regular releases are especially important for minor releases. One of the reasosns why I switched to Foresight Linux because Fedora always pushed releases and so I could never be sure when to get it. Same is true for upstream projects like KDE - if I exactly know I will get a new version next week - and only maybe I wont get feature X that is ok for me. I will still be able to checkout a feature from SVN if I really desperately need to. Also one can establish a new common base on which developers and users work (and therefore a user might not have to start a new app, because a software now has the feature he needs). Releasing is a way of communicating. Its also important to have some major goals and to not look at release cycles uppon them. But for the every day release work I think regular cycles are a good thing.

  8. I might have misunderstood the post on kubuntu not being LTS, but I think it's refered to kubuntu with KDE 4. The kubuntu 8.04 release with KDE 3 will be LTS. Am I wrong?

    Edmundo Carmona

  9. I agree that KDE should adapt to a fixed release date schedule. Moreover, I believe even the smallest open-source project should synchronize its releases with big ones. If all open-source projects can stick to a fixed date consistently, this creates something that is extremely valuable for the business world: predictability and thus lower risks. This will improve the image open-source a lot...people will not be able to assume any more that open source is amateurish and that closed source software is professional. If the consistent fixed release cycle gets popular, it'll be the closed source software that will be seen as amateurish...

    That does not mean software projects should switch to 6-months release cycles! They can do as many releases in a year as they long as they stick the release date of these releases (or release) with the 6-month cycle dates of the 'big projects'.

    The Coccinella project (that includes me) issues 4 or more releases each year, so we have something like a 3-month release cycle. We do 2 of these releases at (or a day before) the day a new Gnome version is released. The other 2 or more releases are more flexible, but they will be on average around 3 months after the fixed release. More releases are possible when we do important bug fix releases e.g.

    I can assume some projects only release once a year or even less. In such a case it would be good if they also could stick that one release to the same date as the 6 month release cycle of Gnome.

    PS: I'm a KDE guy, I never use Gnome.

  10. I have to say I think you're dead wrong.

    You say "Look at how many people left Debian for Ubuntu's regular release cycle" but I say "Look at how many enterprises use Debian because it doesn't contain more bugs than a ghetto kitchen".

    Predictable release cycles do nothing but give people a false sense on stability sicne you said it yourself - make your goals fit the time frame. When you really think on this, how can you meet your goals if you're not actually setting them? How can they be set if, a week from your deadline, you have to drop them?

    The Vista delay didn't "upset" IT managers - anyone who's been involved with managing IT knows that the minute you change from the default "all bets are off" anyway - despite LTS releases, Ubuntu still has a "Universe" which doesn't get full workovers and since default installs of Ubuntu don't meet everyone's needs immediately, you end up pulling in "unsupported" software anyway.

    I dread major upgrades - inveritably interfaces change, there are new features to learn to use, and something you relied on vanishes. This is the drawback of "change" which is why when I have to change, I'd rather the change be "better" than "on time".

    People didn't leave Debian for regular release cycles, they left Debian for a distro that focused on the needs of home desktop users rather than being a good basis for a Free Software system.

  11. @Kevin Dean: the whole idea of this fixed releases dates is not about doing unstable releases on a fixed date. Instead, the idea is that you tell to to outside world: "On this date we will do a stable release. You can already do your planning in advance if you want to deploy this release. There will be no delays. You can hire additional people for this deployment in advance as there *will* be a stable release on that date. What we can't guarantee is that all items we had on our roadmap will be in that release; our focus is to make a stable release on that fixed date and all things that are not yet stable will be delayed to a later release. If there is something in this roadmap you really need in your company, you should verify in the beta releases if this feature is stable. If it is not and the feature is very important for you to be in the upcoming release, you should contribute your patches or pay people to get the specific feature stable in time". So, as you can see , it's the *process* that will get stable and this is unique in the IT sector where it is common that software releases are delayed. With fixed dates, companies can plan deployments of new software versions *years* in advance which is a *valuable* asset!

  12. The Kubuntu debacle, shows why Shuttleworth style "predictable" release dates are broken.

    If Canonical, can't provide LTS to a "stable" desktop that's been around a long time, like KDE 3.5.8 that is *not* getting new features, what can they provide LTS for?

    The clear message is, Cannonical back GNOME and KDE is a 3rd class citizen.

    Shuttleworth is out of order, if he's trying to tell KDE how to move their project forwards. If he wants to influence that, he has to support KDE developers, and KDE much better, so they have more concern for his short-term requirements.

    The whole point about KDE 4, is that it's a Major version update, aka a re-write of very many features to use Qt4, and re-engineer the destkop environment.

    That is not something that the small minded soots, with their nice little charts and planners can control. The project is too big, and the changes too sweeping.

    KDE 4 should be released when it's ready for use, it already has less functionality than KDE 3.5.8, due to things like Plasma replacing Kpanel.

    The right solution, is to provide KDE4 alongside KDE3, and let admins and users migrate over, when their applications and needs are better met by KDE4 than KDE3.

    This happens to be what OpenSuSE 10.3 already does, which is the reason you don't hear any angst coming out of the OS community. SuSE provided destop updates in past for KDE, for users wanting the latest & greatest, may be their experience is actually showing here.

    If you're an end-user then of course you like "predictable" release schedules, just like you would like not to pay taxes.

    But there's no point in having a KDE 4.0, if due to release schedule constraints, it is actually KDE 3.5.8+, and lamb dressed as mutton.

  13. "The Kubuntu debacle, shows why Shuttleworth style "predictable" release dates are broken."

    Why is that a proof? KDE never said it would adopt the predictable release dates...not yet.

    "The clear message is, Cannonical back GNOME and KDE is a 3rd class citizen."

    Indeed, but I don't see why this is relevant...

    "Shuttleworth is out of order, if he's trying to tell KDE how to move their project forwards. If he wants to influence that, he has to support KDE developers, and KDE much better, so they have more concern for his short-term requirements."

    Why needs Shuttleworth to support this? The idea is just that the projects *themselves* *independently* do this. It worked for us at the Coccinella project without any support from fact Coccinella is even not part of any Ubuntu flavor!

    "The whole point about KDE 4, is that it's a Major version update, aka a re-write of very many features to use Qt4, and re-engineer the destkop environment."

    Indeed, but that's also no excuse for claiming the fixed release dates does not work. If the KDE project would have said it would adhere to the fixed release dates and then not being able to release at that date, it tells more about a poor project management. Oh yes, I'm a *KDE* fanboy in case you thought I wanted to start a KDE/Gnome flamewar...

    "KDE 4 should be released when it's ready for use, it already has less functionality than KDE 3.5.8, due to things like Plasma replacing Kpanel.

    The right solution, is to provide KDE4 alongside KDE3, and let admins and users migrate over, when their applications and needs are better met by KDE4 than KDE3."

    IMO the right solution for the delay issue would have been to not postpone the KDE4 release with 1 month, but instead postpone it with 6 months *and* do a full freeze of the KDE4 branch for 1 month. This 1 month then should then have been used to get more features to the KDE 3.5 branch. After this 1 month lots of patches will be waiting to get into the KDE4 branch so that it will be possible to do a beta/alpha/RC/whatever release short after this 1 month period. The advantage is that there will be a longer testing period for KDE4, more features will get in KDE4, KDE4 will have more features than KDE 3.5.x, and users will get 2 very good KDE releases.

    "But there's no point in having a KDE 4.0, if due to release schedule constraints, it is actually KDE 3.5.8+, and lamb dressed as mutton."

    I agree, but IMO it would have been better to postpone the KDE 4.0 release even longer and do a more extended 3.5.8+ release instead.

    PS: my analysis of why the KDE project did not (yet) adopted the fixed release cycle is probably the large influence of SuSE/Novell and Mandriva in the KDE project. They fair *Ubuntu and thanks to the short delay of KDE 4.0 they have an advantag of 6 months as there will be no LTS of next KUbuntu whilst they can do an 'LTS' release with KDE 4.0 included (they provide long term support for KDE 4.0 sooner as they employ several key KDE devels whilst the KUbuntu project/Canonical doesn't to the same degree).

    If Novell, Mandriva, amongst others really influenced (by their contributions e.g.) the KDE project to delay KDE 4.0, it is really stupid. Ok, in the short term it may be good for these companies, but a common, fixed and synchronized release cycle would transform the open source community and the companies around it in some kind of cartel (like OPEC for oil) which will make it easier for the whole group to compete with non-open source software...

    KDE should not adopt the fixed release cycle to please Shuttleworth, but because it is in its own self-interest in the long term.

  14. KDE's been going a long time, and it's had a traditional approach to version numbering.

    Just because Shuttleworth likes a time based release date, doesn't make it right.

    There's not a "proof", but it's a complete mess.

    Kubuntu won't be taken seriously because of this.

    You don't seem to understand the word "if". You may like pronouncements, and agree with Shuttleworth but others are free to do things in the way that has served most development cycles best.

    Evolutionary uprades and small steps, may suit release dates, but re-developments don't. It's ridiculous to start saying the KDE project should go with that method, when it obviously won't work.

    They have enough trouble with KDE4.0 release as it is without imposing artificial deadline, dropping the newly developed stuff just to get something shipped on time.

  15. I recommend anyone commenting at all watch the entire KDE Keynote presentation done by Mark Shuttleworth.
    First, he suggest regular releases for KDE, which I agree with overall.
    Second, he does NOT suggest doing it for KDE4! He's AGAINST that.I agree with that as well(in fact I think it's too early to call the current state anything but a late beta, but I use late betas, often).

    So let's all cool our heads and try to look at this from two sides.

    If KDE is more concerned with the quality of the product as opposed to more people using it, that's fine, but regular stable releases WILL bring more users in. That said, I wish Gutsy had been more stable. I had no real issues after the RC freeze, but I've heard other did have problems.

  16. "Evolutionary uprades and small steps, may suit release dates, but re-developments don't. It's ridiculous to start saying the KDE project should go with that method, when it obviously won't work."

    Explain me why 'obviously'? It works for us great with Coccinella and the Gnome people also do not seem to have any trouble with it. Agreed, it will require a change in the KDE project, but claiming that the KDE project is not able to undergo such a change is a bit too pessimistic I hope.

    @TheGZeus: the keynote of Shuttleworth was before the KDE project delayed the KDE 4.0 release with 1 month. I also agreed before this delay that KDE 4.0 should not be 'synchronized', but when they delayed the release with 1 month because it was not ready yet I changed my mind. They should have took this opportunity to delay the release with 6 months to get a rock-solid release (I'm hearing stories that KDE 4.0 is not that polished yet... :-( ).


Post a Comment

Popular posts from this blog

Using the Cisco console in Linux

Unscientific Linux Popularity Contest

Linux NIC teaming recommendations