I think Nuno's point is very interesting and worth thinking about. To stick with the firefox example, since they started releasing every ortography fix in the settings dialog as a new major version, I think attention in the media to their releases has declined a lot -- nobody cares any more that a new version of firefox was released since it happens every three days.
Of course this is not the only and not the most important criterion, but I still think an eye should be kept on it. Greetings, Sven 2013/7/8 Ingo Klöcker <kloec...@kde.org>: > On Monday 08 July 2013 22:14:28 Aurélien Gâteau wrote: >> On Monday 08 July 2013 16:26:00 laurent Montel wrote: >> > Le lundi 8 juillet 2013 16:11:05 Frank Reininghaus a écrit : >> > > Hi, >> > > >> > > 2013/7/8 Àlex Fiestas: >> > > > Now that kde-workspace and kdelibs are going to be frozen (which >> > > > in >> > > > theory >> > > > means less work for everybody) I'd like to propose a new release >> > > > schedule >> > > > to be applied starting with 4.12. >> > > > >> > > > Basically the idea is to cut testing time and compensate it by >> > > > keeping master always in a "releaseable" state, now that two >> > > > major components are >> > > > frozen it looks like it is a good time to get used to it. >> > > > >> > > > You can read all the proposal in: >> > > > http://community.kde.org/KDE_Core/ReleasesProposal >> > > > >> > > > Before sending this email I have checked with distro people, >> > > > i18n >> > > > people, >> > > > other developers and almost all of them seemed to either like or >> > > > be >> > > > neutral >> > > > about it (only one exception :p) so I hope that the proposal is >> > > > not a >> > > > complete disaster. >> > > > >> > > > As its name indicates, it is a proposal, so please be >> > > > constructive in >> > > > the >> > > > feedback, we can change as many things as we need. >> > > >> > > I like the idea (from the Dolphin development point of view). Most >> > > of >> > > the changes that went into master during the past months had >> > > already >> > > been tested rather well before they were merged, and the remaining >> > > regressions were found rather quickly by people who use the master >> > > branch a lot. Therefore, it would have been nice if some of the >> > > improvements could have been shipped to users sooner - quite a few >> > > bugs that had been fixed in master (with patches that were IMHO >> > > too >> > > intrusive for the 4.10 branch) months ago were reported again and >> > > again. >> > > >> > > @Laurent:you say that you have "a lot of features to implement", >> > > and >> > > that this would not be possible with a shorter release schedule. >> > > But >> > > wouldn't it be possible to implement some of the features for the >> > > next version and the rest for the one after that? >> > > >> > > If you think that you >> > > need more time to stabilize a feature in the master branch, then >> > > maybe developing the feature in a separate branch and merge it >> > > once it's finished might be a good idea? >> > >> > No it’s not a good idea because nobody tests branch you can see pb >> > that we had when we merge akonadi branch (last big changes). >> >> It is true that we have a problem with getting people to test >> branches. But this problem is independant from the release schedule: >> I believe developing in branches is a good way to work, no matter if >> releases are created every 3 or 6 months. >> >> Having said so, I think Akonadi is a bad example because: >> - It was a huge change, quite the equivalent of a rewrite >> - It was affecting personal data > > Akonadi was developed in a branch. Okay, this branch was called master > and the stable branch was called KDE 4.4 (IIRC), and, of course, this > wasn't nice for people who built everything from master. But we tried to > communicate very clearly that master was not to be used for anything > expect for KDE PIM development. > > And, of course, we did consider using a proper branch, but then we would > have had to maintain 3 branches: KDE 4.4, Akonadi, and master. Given > that we didn't and still don't have enough people to even maintain the > Akonadi branch (aka master) I still think that this decision was the > only sensible one. The only feasible alternative would have been the > deletion of master until the first Akonadi-based alpha release. > > But all of this is stuff from the past. When we do Akonadi 2 ;-) we'll > probably choose a different path. > > > Regards, > Ingo