Linked by Thom Holwerda on Tue 29th Jul 2008 20:39 UTC, submitted by vege
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.
Thread beginning with comment 325112
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2007-02-17
I understand very, very well how it works.
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:
That is silly.
...
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.
...
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
RE[7]: Don't look back
by google_ninja on Thu 31st Jul 2008 14:11
in reply to "RE[6]: Don't look back"
Member since:2006-02-05
Missing functionality is different then removing existing functionality, and very different then putting out half done functionality that hasn't been tested and is full of bugs. This is what I was saying, kde 4.0 is the exact opposite of an iterative process, they basically disappeared for a year and came back with something completely different.
Member since:2006-09-10
Recent Original Stories
Recent Comments
Headlines
Random Comments
Random Stories
Random OS Link
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.