On Wednesday 29 January 2014 13:52:43 Sebastian Kügler wrote: > Hi all, > > We said that we wanted to release Plasma Next early this summer, so it's > about time we nail down a release schedule. > > Proposed Release Schedule > > * Mon, 10th March Feature Freeze > * Thu 13th March Beta 1 > * Tue 15th April Beta 2 > * Thu 15th May Release Candidate > * Tue 17th June Plasma 2014.6 Final > > This gives us another good 5 weeks to finish missing features we identified > during the sprint, and then 3 months in which we can make it really shine > for release. > > What do you think?
I suggest to significantly increase the number of intermediate releases. One month between RC and final is too long. 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 ;-) So as what Eike already suggested: first versions should be Alphas, afterwards I suggest more betas and more release candidates. Cheers Martin [1] This obviously needs some definition of what we consider a release-critical bug
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
