I just watched Mark Shuttleworth’s Keynote on aKademy. The discussion afterwards was mainly dominated by his suggestion to switch KDE’s development cycle to a 6 month release cycle. Here is a closer look at what Mark said – and what KDE did in the past.
What Mark said
It is important to point out what Mark said exactly:
If you guys articulate it and make a commitment to shipping something round about the same time as Gnome did, we would made a converse commitment and that is we’ll ship your stuff very shortly after you do.
It is a promise in vapor ware on both side: the KDE team would promise to ship the next KDE version no matter what it costs, and the same is true for Kubuntu. In this regard the priorities must also be clear:
It boils down to this: No single feature is more important than the release.
It would mean that only these features are included which are really stable enough at that time – everything else would have to wait another release cycle to be included with the next KDE upstream version.
Of course, this would have several advantages and disadvantages:
Advantages
The biggest advantage would be that a recent KDE would be included in each new Kubuntu release: this would give the users a much better experience and it would also mean much faster feedback for the KDE developers. Also, the drumbeat resulting from this release commitment would be enormous: K/Ubuntu, Gnome, KDE, the kernel and maybe even OpenOffice all releasing in the same time frame would create a rhythm hard to ignore. Also, it is likely that other distributions would pick up this release cycle: in these days many of the distributions try to keep a periodic release cycle. And it makes sense for all desktop oriented distributions to take over the release cycle of the main desktop environment. Ubuntu does it, Fedora just stated that they are going to do the same.
It would be easier for the distributions to plan and organize releases, and it would enable them to ship the newest technology available all the time.
Disadvantages
There are mainly two reasons against such a cycle I can think of at the moment: first of all the developers would have to get used to this kind of pressure and rhythm, and they would have to adopt it. New features would have to be coordinated quite exact and new, complex features depending on each other would become quite difficult. This is possible, but requires for example a very balanced and thoughtful release coordination team.
The second reason is press: With the current situation there are Open Source news all the time. But when all projects start to sync suddenly there would be just too much information all 6 month with much less notable events in between. Just imagine the news when KDE and Gnome would release new versions in the same week: “KDE vs Gnome”, etc.
Also, smaller projects would have it difficult to gain enough attention if they would adopt the release cycle (although they would get more if they would a-sync their release cycle).
I’m not sure how the press thing would work out for the different projects – maybe it would hurt them, maybe not. Maybe it would even lead to more attention by broader media (evening news and so on).
What KDE actually did
The question is now if KDE could even adopt such a release cycle. Would the project be able to do such a thing? Or would it be so alien that it could hurt the project?
To answer that question I had a look at the KDE 3 releases:
| KDE 3 releases over the time |
| release number |
release date |
time difference to
previous release |
time difference
between major releases |
| 4.0 (expected) |
23 October 2007 |
154 days |
that doesn’t count – but:
693 days, roughly 23 months |
| 3.5.7 released |
22 May 2007 |
117 days |
– |
| 3.5.6 released |
25 January 2007 |
106 days |
– |
| 3.5.5 released |
11 October 2006 |
70 days |
– |
| 3.5.4 released |
02 August 2006 |
63 days |
– |
| 3.5.3 released |
31 May 2006 |
64 days |
– |
| 3.5.2 released |
28 March 2006 |
56 days |
– |
| 3.5.1 released |
31 January 2006 |
63 days |
– |
| 3.5 released |
29 November 2005 |
47 days |
258 days, roughly 8 1/2 months |
| 3.4.3 released |
13 October 2005 |
78 days |
– |
| 3.4.2 released |
27 July 2005 |
57 days |
– |
| 3.4.1 released |
31 May 2005 |
76 days |
– |
| 3.4 released |
16 March 2005 |
98 days |
209 days, roughly 7 months |
| 3.3.2 released |
8 December 2004 |
57 days |
– |
| 3.3.1 released |
12 October 2004 |
54 days |
– |
| 3.3 released |
19 August 2004 |
71 days |
198 days, roughly 6 1/2 months |
| 3.2.3 released |
9 June 2004 |
51 days |
– |
| 3.2.2 released |
19 April 2004 |
41 days |
– |
| 3.2.1 released |
9 March 2004 |
34 days |
– |
| 3.2 released |
3 February 2004 |
20 days |
371 days, roughly 12 months |
| 3.1.5 released |
14 January 2004 |
120 days |
– |
| 3.1.4 released |
16 September 2003 |
49 days |
– |
| 3.1.3 released |
29 July 2003 |
71 days |
– |
| 3.1.2 released |
19 May 2003 |
40 days |
– |
| 3.1.1a released |
9 April 2003 |
20 days |
– |
| 3.1.1 released |
20 March 2003 |
51 days |
– |
| 3.1 released |
28 January 2003 |
38 days |
300 days, roughly 10 months |
| 3.0.5a released |
21 December 2002 |
33 days |
– |
| 3.0.5 released |
18 November 2002 |
40 days |
– |
| 3.0.4 released |
9 October 2002 |
51 days |
– |
| 3.0.3 released |
19 August 2002 |
48 days |
– |
| 3.0.2 released |
2 July 2002 |
41 days |
– |
| 3.0.1 released |
22 May 2002 |
49 days |
– |
| 3.0 released |
3 April 2002 |
– |
– |
As you can see the time differences between the major releases (3.x) do vary around 8 months. Industry partners need an at least rough release plan, and users are expecting something new every once in a while.
The minor versions where a bit more periodic, but also with huge gaps. However, you could say that there was a minor version every second month.
The major releases vary up to a certain point, but if you only take 3.2 till 3.5 you have a mean of 7.3 months with a standard deviation of 1.32. That is of course not comparable to a fixed release cycle with 6 months, but also not that bad. Neglecting some gaps the minor version also had a release every second months.
Just for comparison: Gnome has a major release every six months. The minor releases seem not to be bound to a fixed date: there were 28 days between 2.18.0 and .1, but 49 days between .1 and .2.
So according to these numbers a switch to a 6 month release cycle would be something totally new for KDE!
Worth a try
Although such a drastic change in preparing releases would mean a lot of change for KDE I think it is worth a try. KDE should work on better release politics anyway to get at least some sort of stability.
Lookin (now) at these numbers it turns out that a switch to a fixed release cycle would require some changes – but not that drastic ones. So from that regard a switch to a periodic release cycle looks at least possible.
There are other possible advantages: it is much easier to talk to corporate users, ISVs and distributors if they can predict the next releases. And KDE has matured enough to listen also to corporate users. And of course: it would be more fun for the users: having a major release in a regular time frame would be more fun to follow. Last but not least it might even attract new developers.
So there are two questions: first, will KDE switch to a fixed release cycle, and second, will KDE switch to a 6 month cycle? But that is up to the developers, they will have the last word. Until now now one spoke out – except Sebastian Kügler, who is opposed to that idea I’m anxious to hear other comments about that topic.
Update:
Kurt Pfeile thankfully spotted a small but important mistake: in the calculations I missed the KDE 3.4 release and calculated the difference between 3.3 and 3.5. This changes the view on the release cycle. The parts in the text are corrected. I’m very sorry for this mistake and the inconvenience it might has caused. I will have an extra look next time I calculate such important dates and time frames. Thanks again Kurt for your remark about that.
But as an interesting side note: afaik this article never made it to Digg or any other larger news site. It is just a piece of information everyone wanted to know. In general I see that howtos and reviews are the most often read pieces – and not for example information about changes in the kernel subsystems. However, these information lately appeared as references on important and large news sites so I was “rewarded” there as well in some kind. And, being used as a news source by larger news sites feels good.
And I had 1 453 comments.
