Submitted by Most mainstream distributions, like Ubuntu, Fedora, and Mandriva, have already adopted a time-based release schedule, meaning that releases are not done on a feature basis, but according to a pre-determined time schedule. The Debian project has announced that it has adopted a time-based release schedule too.
Where most time-based distributions have a schedule of round and about six months, Debian takes another approach, obviously because Debian is more about stability and longevity than about the latest and greatest features in each release. As such, the project adopted a two-year release schedule, with a development freeze every December of odd-numbered years, with the actual release following in the first half of the following year.
Time-based freezes will allow the Debian Project to blend the predictability of time based releases with its well established policy of feature based releases. The new freeze policy will provide better predictability of releases for users of the Debian distribution, and also allow Debian developers to do better long-term planning. A two-year release cycle will give more time for disruptive changes, reducing inconveniences caused for users. Having predictable freezes should also reduce overall freeze time.
The first of this new type of freeze will happen December 2009, making the time between the current release and the next one rather short – this is a one-time occurrence. “To accommodate the needs of larger organisations and other users with a long upgrade process, the announcement reads, “the Debian project commits to provide the possibility to skip the upcoming release and do a skip-upgrade straight from Debian GNU/Linux 5.0 (Lenny) to Debian GNU/Linux 7.0 (not yet codenamed).”
Despite the relatively short development time, the next Debian release, codenamed Squeeze, will still have some interesting features, such as multi-arch support, which will make it easier to install 32bit packages on 64bit installations. It will also sport an optimised boot process which will reduce boot times and improve reliability.
This schedule will align Debian Stable very close to what an Ubuntu LTS will ship.
It will be interesting to see if Ubuntu will ship the Debian versions of the Kernel and Gnome. That would be a fairly major shift towards stability. I would love that for LTS releases.
True. Shuttleworth is the one to blame. Debian move is a capitulation to Ubuntu… and I don’t think it’s for the best. I just hope they know what they do and still focus on quality, not anyone’s marketing needs.
IMHO, I don’t think that a strict, or semi-strict like now Debian’s, release cycle is productive, at least with short cycles, and I believe is detrimental first to stability and second to innovation. I wish I’m wrong here.
I say this because I think that Ubuntu has been living up until now on the fruits of Debian and not on any merit derived from decision making in the distro, aside of marketing, obviously. As an example of bad administration, language packs in launchpad are NOT sync with upstream. My upstream KDE translations, for example, are not sync back and forth in Ubuntu. This is horribly insane.
Edited 2009-07-29 14:22 UTC
I think that desktop linux users are to ‘blame’, not Shuttleworth although placing blame seems too severe at this point. Fedora, Mandriva and Ubuntu all have ‘regular’ release intervals and that is what desktop users have come to expect. If anything this move is to bring some Ubuntu users (and other desktop users) to Debian, not to bow to Ubuntu.
Honestly the erratic release cycle of debian is the largest hurdle keeping me away from it.
Yes.. because.. how would you EVER be able to sleep not knowing if you were to upgrade the software on your computers in april or july? oh teh horror!
Or in Debian’s case, *which* April or July. This matters for corporate desktops. I know. I administer them. And Debian’s cavalier attitude toward release planning is the #1 reason that we don’t even consider using it.
Edited 2009-07-29 15:37 UTC
Do you really administer Corporate Linux Destops? That’s awesome. Which distro do you use then? Red hat releases are pretty slow. As are Suse ( last I checked, has this changed?). Ubuntu seems to be the most regular releases of something that might be installed on a corporate desktop.
Yes. Since 1999. But things didn’t really start picking up until 2004. That was “the year of the Linux desktop” in my professional world.
Yes. It is. 🙂
I’ve traditionally used a combination of Fedora and CentOS (RHEL, by any other name.) However, I recently finished migrating everything to Ubuntu. So far, my customers and I have been *much* happier with it.
Edited 2009-07-29 16:01 UTC
no, it doesnt really matter to corporate desktops, unless ofcourse you need something to occupy yourself with and thus feel like upgrading peoples desktops very regularly?
You are presuming to tell *me* what matters to my customers, and to me as an admin? Careful. I’m the one with the experience in this particular area. (Or please present your credentials.) You don’t have to deal with the user complaints about, for example, how certain business critical PDF’s won’t open in or print from Evince when you know that the latest version can handle it.
And just try apt-get’ing Evince from testing. It will destroy your Debian system.
It is possible to use a distro with a long release cycle, like CentOS. We’ve done it. But compared to what we are using now, the long release cycle distros are more pain than gain for corporate desktop use. And Debian has the longest release cycle of them all. With unpredictability thrown in just to make it even more appealing.
Edit: In the interest of fairness, I should note that as of RHEL6, Red Hat’s release cycle has become even less predictable than Debian’s. Which also affects CentOS, of course. Though one can’t blame the CentOS guys for that.
Edited 2009-07-29 17:23 UTC
Creating select backports isn’t terrible complicated.
It is when it pulls the entire next release of the DE into a distro version that it didn’t come with. And even if it worked, I can’t justify doing that kind of completely unsupported open-heart surgery on our business critical desktops. Certainly not when there are better, and supported, solutions.
Edited 2009-07-29 17:31 UTC
Just curious, but why don’t you just use Acrobat Reader then in a corporate environment if .pdf’s matter that much.
Seems worth it getting the proper ‘original’ app for this, or was it just and example and not really the only issue.
Myself, I can’t find anythin wrong with a two year old system that’s still receiving security updates, but then I’m a home user. Lenny is the most stable/solid I’ve tried though in recent months with absolutely everything working fine (even wireless and with added kernel modules for Vbox and vmware) being the smoothest experience ever, and I thought that would count for something in the business world too?
We used to. Adobe’s product has horrors of its own. But yes, that was only an example. The flexibility of being able to upgrade at reasonable time periods turned out to be more valuable than the ‘stability’ of long release cycles. That experiment took about four years to complete, and there is no doubt in my mind as to the result.
Bingo. Supporting 70 users in a business environment is *completely* different than simply satisfying one’s self. My users, collectively, do a lot more different things than I do. Print about 150,000 pages a month. And problems which would have you or me throwing up our hands in digust at the website, or pdf generator, or whatever, in question, and simply refusing to deal with that entitiy… I actually have to solve. No matter how badly the entity perverts standards. And no matter how distasteful the “solution” might be. (e.g. I have a number of people using IE6 under Wine)
It’s all challenging enough when I’m dealing with the current software versions. The added impediment of dealing with where the OSS world was 2 years ago makes it that much worse. And despite all the advice one gets about “just get this or that from testing” (or unstable!) the fact of the matter is that doing so is completely unsupported. When people casually advise me to do that on my live servers, I’m tempted to send them some sort of “assumption of liability” document to sign and get back to me. But while the community is full of advice, I doubt many would have it signed and notarized and send it back.
Lenny was released in February of this year. We upgraded our biggest server in April, 2 months later. Just out of curiosity, because so many Debian fans come out of the woodwork to ooze about how wonderful Debian is, I decided to do a quick eval on the new server. Lenny wouldn’t even install. Couldn’t see the SATA controllers. The kernel was too old to recognize that hardware. I shook my head and continued on, installing the distro that we had decided to use. And it went flawlessly.
Just as a note, Lenny won’t install on my workstation either. SATA problem again, on a board I purchased last July. However, Fedora 10 and Ubuntu 8.10, released 4 months previous to Lenny, have no problem with it.
Edited 2009-07-30 12:45 UTC
oh teh noes, a few applications cause you to need to have regular operatingsystem wide release schedules… no offense, but i think im beginning to understand your issues a little bit better
You’re going to have to help me with that one.
My view can pretty well be summed up as:
Why fight my IT battles (which are challenging enough in this Microsoft World) with ancient OSS tools when there are very stable distros available which give me the benefits of the tremendous amount of work done by the OSS community over the past few years without having to patch in unsupported chunks from repos called “testing”, “unstable”, or “experimental”?
To hear some Debian community members talk, you’d think all non-Debian distros were on the level of Windows 98. When in fact I’ve had far more trouble with Debian than with any other Linux distro (except Fedora, of course).
I’m sure that Debian on an old server that just sits there year after year churning out work is very stable. But then, so are most Linux servers.
An XDMCP server is like no other. It is a living, evolving environment that requires change and adaptation as my desktop users need to do new and different things. Because serving desktops is a very different workload than any other kind of server ever sees. The apps actually *do* bit-rot. It is a more challenging workload in many ways.
That said, administering desktop servers is a very rewarding and interesting thing to do. And despite the name “server”, it really requires a different kind of distro than what is generally supposed to be “good for servers”.
My point was perhaps not clear. I was more pointing towards the length of time between releases and the variability of that time from one release to another.
Although it’s true that a large majority of desktop linux users care about having the latest apps, I am more concerned in the case of Debian with hardware support. Stable releases use old kernels right out of the gate and then 18 months later…they are even older.
I build my own computers so a fairly recent kernel is important to me but it comes down to personal preference. Hardware support IS important to me afterall….
For me, it’s that most of the packages in stable are pretty old – and, if you want something new, maybe something that came out in the last six months (or a year), it might not be available at all. Unstable doesn’t necessarily help much: it’s, well, unstable, and while it’s packages are a little newer, it may well not have what you want either.
Exactly. The FOSS world moves faster than Debian. Nothing wrong with that; just an observation.
@kragil: the three-letter acronym in “Ubuntu LTS” stands for “Long Term Support” instead of “Long Term Stability”.
This means users of this release will receive updates over an extended time frame compared to other Ubuntu releases. Also, commercial support can be paid over a longer time frame.
Accordingly, there is *NO* reason why an LTS release would be designed to be more stable than any other Ubuntu release. In fact, there is no guarantue that an LTS release will give you additional stability and I believe some people experienced more stability issues just after release of Ubuntu 8.04 LTS than just after release of Ubuntu 7.10.
To summarize, *all* Ubuntu releases are designed with the same quality testing procedures. Hence, the only reason why there may be differences in stability between releases is statistical.
PS: of course LTS may become on average more stable at the end of their lifetime as they receive updates over a longer timeframe. So yes, you will statistically get more stability, but only if you only install the LTS release about 16 months (*) after its initial release date.
(*I believe this is how long normale Ubuntu releases are supported?)
That’s a shame.
While there should be a reasonable deadline concerning the release date, Debian should be released only when it is ready.
That was the biggest strength of the project, offering a great stability, suitable in a professional environment.
Now distros developers focus too much on the desktop and forget that stability is the key and that Gnu/Linux is strong on the market server, whereas the desktop still remains a huge challenge.
I bet that in the future, the delay will be shortened.
I even doubt that Debian will now survive to Ubuntu…
Read the whole text.(Thom picked a misleading headline, I am not to blame
) The release will not be time based, only the freeze will be time based. It will still be released “when it is done”(tm).
It’s still a time-based release cycle – it’s just that because Debian chose a longer timeframe, they also have more leeway between dev freeze and release. Ubuntu also has leeway between dev freeze and release, it’s just shorter because the cycle is shorter as well.
Well, what Debian is doing is not a time based release cylce like Fedora, Mandrake or Ubuntu. They will freeze Debian Testing in december and they will start fixing RC bugs. There is no real time line from there on out. Theoretically they could release in january (highly unlikely) or in june (knowing Debian it could even be september)
So time based freeze is a more accurate description of what they are doing unless you consider within +-6 month a fixed time.
http://mdzlog.alcor.net/2009/07/29/debian-is-not-switching-to-time-…
Matt knows more about Debian than 99.99% of OSnews posters .. so for me this argument is settled.
It is misleading stating that
“Debian Adopts Two-Year Time-Based Release Cycle”.
The article here quotes the following
“Time-based freezes will allow the Debian Project to blend the predictability of time based releases with its well established policy of feature based releases.”
To break it down, they state that they blend two things
1. Time-based release cycle
2. Feature based release
What they get is not a
Time-based release cycle, but a
Time-based freeze cycle.
This change does not indicate that Debian will not be “ready” when a new release arrives. Probably what will occur is that those “not ready” packages will not be shipped in their lastest version, preserving a stable one.
Having an idea of when a new version of Debian will be available – well, I can wait one year at all – is good for planning.
Anyway, if the release looks unstable for you, you can simply choose not to install it and wait for a patch or the next release.
For the end user, it’s not when the distro releases but when the current distro stops recieving update packages.
I used this approach with Mandriva for years before giving Debian it’s due. When I stop seeing updates for my current Mandriva version, it’s time to upgrade. 2007.1 isn’t getting updates so it’s time to choose between 2008.1 and 2009.#. Ok, it would have been time but Lenny has replaced it on all but my last desktop. In my current case, when 2008.1 on that stops receiving updates, I’ll have already confirmed my final question; how does Lenny (or Squeeze by that time maybe) support my Nvidia GPU and Hauppauge tuner board.
(checkinstall has single-handedly taken care of anything not in the repositories that has to go in from tarball.)
It’s a two year release cycle; they’ve left themselves plenty of room to get each release right. They’ve given themselves four times the time it takes for a Fedora or Ubuntu release, to make (what will probably be) fewer, less-radical changes.
I’m an active Debian user (20 servers on Lenny and 10 workstations on Testing) and having more predictability is always good for planning. And Lenny -> StableAfterNext upgrade promise is wise move.
Although I must admit that planning a freeze in 4 months is pretty radical – many important upgrades (kernel, x.org, etc) have still not reached to Squeeze and it still looks a lot like Lenny (with the exception of DE – KDE, Gnome and Xfce have all been upgraded).
The following packages have been kept back…
Ever tried the command: “apt-get dist-upgrade” ?
This will upgrade packages that have been kept back because they require dependencies that were previously not installed.
I mainly use (server side) FreeBSD and for Linux had been using Debian until I switched to Ubuntu – Debian simply was too outdated for me although for what it did support, it was solid. I can live with a two year cycle and probably will switch back to Debian. I always liked Debian on the server side.
This new decision can be especially useful for organizations and companies that use Debian. Their IT people can predict better when their Debian installations will need to be upgraded, and reserve time for it. Or if stable itself might not fulfil their needs completely they can have a better idea whether they should maybe install some newer software from backports etc. or if they could afford just wait for the next release and so on.
That aspect, predictability, is one major reason why most commercial Linux distributions already use time-based releases. You could say that it improves the usability of a distro if you can have at least some idea of its release schedule.
Of course, it is great that at least some distribution, Debian, still emphasizes stability so much, but I don’t think that a 2-year cycle will be so big a problem in that respect. The developers will just have to make certain decisions and choices in order to reach stability in a more fixed schedule from now on. Also, the main dilemma of Debian’s stable releases, that of stable packages becoming outdated compared to the improved upstream versions will be less of a problem from now on, making Debian much more attractive to even many new users who may have prefered other distros to Debian before.
But it doesn’t do that at all! Just having a predictable feature-freeze cycle doesn’t really do anything to make releases more predictable, really, because there’s still a bugfix period. In the last few Debian releases (well, ever since Woody, really), that bugfix period was quite lengthy.
Let’s take a look at the Debian release dates and times so far:
Debian 1.0 – never officially released
Debian 1.1 – 1996-06-17
Debian 1.2 – 1996-12-12 – 6 months
Debian 1.3 – 1997-06-05 – 6 months
Debian 2.0 – 1998-07-24 – 13 months (25 months since Debian 1.1)
Debian 2.1 – 1999-03-09 – 8 months
Debian 2.2 – 2000-08-15 – 17 months (25 months since Debian 2.0)
Debian 3.0 – 2002-07-19 – 23 months
Debian 3.1 – 2005-06-06 – 35 months
Debian 4.0 – 2007-04-08 – 22 months
Debian 5.0 – 2009-02-14 – 22 months
It seems like a 24 months freeze cycle for major releases is what
they have been going for since the beginning and finally deciding
on it seems like the natural thing to do.
Looking at things in this light shows this decision won’t
rock the Debian boat and affect stability in any way.
Rowing the boat will just become more synchronized.
I would have said:
Most mainstream distributions, like Ubuntu, Fedora, and Mandriva, have already adopted a time-based release schedule, meaning that they release whatever crap they have ready at that point in time, regardless of its stability and quality.
I quite agree, not fully but I agree. They should at least use a 1 year time frame.