Previously Wichert Akkerman wrote: > Now that we have a new framework team it is time to start planning the > 3.1 release. 3.1 is intended to be a low-risk upgrade which can follow > the 3.0 release quickly. The release cycle has to be short so we can > get things out to people. Here is my proposal: > > - all proposed updates for have to be submitted by christmas > - framework team finishes reviewing by january 9 > - accepted changes are merged in the days after that > - first pre-release for 3.1 happens on january 15 > - final release for 3.1 happens first half of february > > In order to make reviewing simple all updates have to be submitted in > the form of a working buildout. And to keep the 3.1 process smooth they > have to include all migrations, finished user interfaces and > documentation. We will not do any polishing after merging - that has to > be done beforehand. > > Judging by the current activity I expect there to be only 2 or 3 > proposals in a mergeable state. That is not much, so you should be able > to enjoy some christmas vacation as well :)
So by now a number of you have complained that this schedule does not work very well. So I think it is time for me to mention another reason I have for setting a short deadline, even if that is not attainable for most people: at the moment almost all big development is deadline-based. There is very little happening when there are no deadlines looming in the near future. That is very problematic when planning releases: we see too many changes in a short time period which puts a lot of load on everyone and it will very easily lead to delays. We have been seeing that for pretty much all releases. What I would like to see is more continuous development process where new stuff is being developed all the time and submitted for inclusion when it is ready. If we have a shorter release cycle that should be able to make things a lot smoother. The 3.0.x maintenance releases that we have been doing for the last couple of months prove that we can do time-based releases without too much hassle. KSS is a good example of how things should work: they are always working on improving KSS and have their own release schedule. The jquery work Martijn Pieters has done is another good example: he implemented that completely at his own time and pace and it's been almost ready for merging for a month already Giving everyone the freedom to develop at their own schedule combined with making smaller by making quicker releases that guarantee that things will not collect dust for half a year or longer before they can be merged. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
