Linked by Thom Holwerda on Tue 29th Jul 2008 20:39 UTC, submitted by vege
KDE 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 325107
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Don't look back
by google_ninja on Thu 31st Jul 2008 03:04 UTC in reply to "RE[2]: Don't look back"
google_ninja
Member since:
2006-02-05

The paradox is that without the KDE developers setting 4.0 in stone and working off from it, 4.1 would probably not have happened and certainly wouldn't be as good as it has turned out to be.


That is silly. The only reason that would be the case is if the kde core developers have no communication at all with the developers working on the platform. Since all the mailing lists are open, we know that isn't true. KDE4 was a milestone, not a release. 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.

Reply Parent Bookmark Score: 2

RE[4]: Don't look back
by lemur2 on Thu 31st Jul 2008 03:18 in reply to "RE[3]: Don't look back"
lemur2 Member since:
2007-02-17

"The paradox is that without the KDE developers setting 4.0 in stone and working off from it, 4.1 would probably not have happened and certainly wouldn't be as good as it has turned out to be.
That is silly. The only reason that would be the case is if the kde core developers have no communication at all with the developers working on the platform. Since all the mailing lists are open, we know that isn't true. KDE4 was a milestone, not a release. 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. "

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".

Reply Parent Bookmark Score: 4

RE[5]: Don't look back
by google_ninja on Thu 31st Jul 2008 03:57 in reply to "RE[4]: Don't look back"
google_ninja 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.

Reply Parent Bookmark Score: 2

RE[4]: Don't look back
by segedunum on Thu 31st Jul 2008 14:15 in reply to "RE[3]: Don't look back"
segedunum Member since:
2005-07-06

That is silly. The only reason that would be the case is if the kde core developers have no communication at all with the developers working on the platform.

News at 11. Software works better in a release early and release often fashion. When you've achieved what you want to achieve in the run up to a release, release it and build off that. That is the certainly the way open source development works, and the way even commercial companies work.

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.

I'm afraid you don't get to decide the requirements for a release. The KDE developers do. If it doesn't work for you then don't use it, and distributors generally make that decision for you by deciding whether to ship it by default. That's the way releasing open source software has always worked.

You can't have release candidates forever, otherwise if they'd waited nine months to release KDE 4.0 they would have had ten times the problems and everybody would have complained bitterly that it wasn't good enough for them anyway.

For some people 4.1 will work great. For others 4.2 or 4.3 will only be good enough as more applications get ported to the platform. There is no black and white.

Reply Parent Bookmark Score: 3

RE[5]: Don't look back
by google_ninja on Thu 31st Jul 2008 15:01 in reply to "RE[4]: Don't look back"
google_ninja Member since:
2006-02-05

Release early, release often means that instead of trying to implement everything at the same time, they all should have focused on one or two things, and got it out in a month or two. a top to bottom overhaul is the exact opposite of release early, release often. You are pretty much arguing my point for me by quoting that.

Reply Parent Bookmark Score: 2