On Wednesday 29 January 2014 16:52:51 Martin Graesslin wrote: > I suggest to significantly increase the number of intermediate releases. One > month between RC and final is too long. +1 > I would prefer to have a series of > release candidates and a release candidate should be exactly that: a > candidate which could be the release. Given the schedule I don't think that > the Release Candidate would count as that, but rather as another beta > without any RCs. In the time of the release candidates I would like to see > us focusing on quality by only addressing issues which are > release-critical. Large work to fix a bug which could end up in yet another > layer of regressions should not be done. Given that I would suggest to not > put a final release date into it. It should be the first release candidate > which has no release-critical bug fixes [1] (idea stolen from Debian). Or > in short: it's done when it's done and not when we hit the date ;-) I love this idea, if we make a perfect RC1 then during the next weeks we can release the final version. If we still have critical bugs we release RC2.
> So as what Eike already suggested: first versions should be Alphas, > afterwards I suggest more betas and more release candidates. Is Alpha unstable code? A release that contains known critical bugs? why do we release them? Are distros going to package Alphas? Is Beta unstable code? A release that contains known critical bugs? why do we release them? Are distros going to package Betas? I'm sure that the answer to those questions depends on the user, and no matter what communication effort we do people will continue having their definitions of betas and alphas. Personally I think we should do a number of pre-releases without any special name, and the moment we think Plasma2 is stable we tag RC1. Cheers. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
