Alec Mitchell wrote:
On Mon, Jun 22, 2009 at 5:12 PM, Alexander Limi<> wrote:
On Sat, 20 Jun 2009 21:32:19 -0700, Martin Aspeli <>

 - We use this PLIP review cycle to start assigning PLIPs to 4.1. There's
no reason we can't and shouldn't start planning for that now. So, if a PLIP
looks like it'll take longer to do, we can still vote +1 in principle, but
target it for a 4.1 release that can come not too long after 4.0 is out.
I agree strongly on this. A process note, I see we have created 4.1, 4.2
milestones — would it be better to create a 4.x milestone like we did on
3.x, so we can say "it'll be in one of the 4.x releases" instead of tying it
to a specific release until we actually know which release it'll make it

I'd say this may be premature.  There are going to be PLIPs which
require a break with backwards compatibility, and which only make
sense for 4.0.  Those we have to assess on their desirability and
feasibility.  If they seem too radical they would be pushed to 5.0.

Then there are the less ambitious PLIPs which don't require
significant changes to add-ons, customizations or documentation.  If
we determine that the change is desirable, it would potentially be
acceptable for any release in the 4.x series.

In that case, what is the purpose in explicitly pushing it into a
later release in the cycle?  Making that decision could discourage the
development of the feature entirely.  If the PLIP developers feel that
they can have the feature ready in the specified timeline, and we feel
that it is a beneficial change for Plone, arbitrarily pushing it to a
later release seems inappropriate.

If the PLIP developers themselves indicate that they may not have
enough time for development, such a decision may make sense.  This
could easily be the case for developers who have submitted multiple
high quality PLIPs.  Beyond that, I don't see how we can make an
objective determination of which features are not right for 4.0 but
are fine for 4.1.

If we are going to be assigning PLIPs to future 4.x releases, I think
we need to have some clear guidelines on which to base such decisions.

I agree that we should defer this decision if we can. But also consider that each PLIP takes a fair amount of effort to review at each stage. In the past, the framework team has become a bottleneck as they've had to review more-than-expected PLIPs. Then we have a merge bottleneck and the potential for more bugs introduced during the merge process, which drags the release out further. For example, will all those "almost ready" add-on products work flawlessly on Zope 2.12? We don't know yet.

I'm not saying we should defer things by default, and the BBB argument is very important w.r.t. going into a .0 release. I'm just suggesting we keep the option on the table to say "yes please, but we need to wait a little bit longer".


Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See

Framework-Team mailing list

Reply via email to