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