Release schedule for Plasma Next

[Martin Graesslin]

On Thursday 30 January 2014 17:48:34 Àlex Fiestas wrote:
> 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.

I like this idea! +1

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140130/5b5d2a32/attachment.sig>