[Framework-Team] proposed plone 3.1 timeframe

Wichert Akkerman wichert at wiggy.net
Thu Nov 22 08:40:47 UTC 2007


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 <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.




More information about the Framework-Team mailing list