Earlier this year, the KDE team released the highly-anticipated 4th major revision of the KDE desktop. Instead of bringing evolutionary changes, KDE 4.0 effectively delivered a complete rewrite of KDE, and as a consequence the first release of the KDE 4 branch lacked a lot of features of KDE 3.x, while also being quite unstable and rough. Many even complained the KDE team shouldn't have released KDE 4.0 as 4.0, but rather as a developer preview release or something similar. During this storm of criticism, the KDE team calmly pointed out that KDE 4.1 would fix many, many of the issues people had with KDE 4.0. Starting today, there's no more pointing towards KDE 4.1: KDE 4.1 has been released today.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-02-05
I understand very, very well how it works. Anything even remotely close to a modern process works the same way in the commercial world, the goal is to have one month release cycles of small pieces of functionality, which lets you deliver business value immediately, tightens the user feedback cycle, and allows the user to drive the direction of development rather then wasting time on things they don't want/need.
That is not an excuse for cowboy coding, it means the scope of every iteration needs to include time for unit testing, integration testing, regression testing, performance testing, and deployment stories. If that means that a feature doesn't get done, it is more important to cut it from the release then to compromise on value by pushing it through.
A release means something is done. Something being done means that it has been fully tested. If it hasn't been done, it shouldn't be released. If all you can manage to put out in a release is a single feature, it is better to do that and have it be done rather then compromise on what done means, and release half a dozen features. That is how the commercial world works at any rate.
Member since:2007-02-17
If indeed you did understand very, very well how open source code releases works, and you were being fair, then you would not have opined the following:
...
The only reason they made it a release is because they were already late, and didn't want to look bad by waiting another 7 months to do it right.
Rather, if you understood how it works, you would have understood that KDE 4.0 was ready for a .0 release ...
KDE 4.0 was indeed missing a great deal of functionality, no doubt. It was not ready if it were a commercial program, but it was ready for release in the sense it was an open source project following a "release early, release often" cycle of development.
For open source development programs, .0 releases do indeed lack significant slices of the eventual functionality. That is the way they are done.
Edited 2008-07-31 06:53 UTC
Member since:
2007-02-17
Releasing of open source software doesn't work like that, it is NOT commercial software.
Perhaps some references might explain it a bit for you:
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar...
http://radio.weblogs.com/0103807/stories/2002/12/01/understandingTh...
"If you are an ex-commercial developer then you want desperately to reach a "1.0" stage or a "near functional", "mostly baked" stage before going live. You wouldn't want to release something piece meal, would you? After all -- that's the way it's done.
Actually no. In the Open Source world, that's not how it's done."
This is not a new concept for open source:
http://www.google.com.au/search?hl=en&q=%22release+early+releas...
45,200 hits for the open source catchcry phrase that applies here ... "release early, release often".