[Framework-Team] Re: The new Plone 4.0, was Re: Plone 3.5

Ross Patterson me at rpatterson.net
Tue May 5 20:05:26 UTC 2009

In general, +1.  More below.

Hanno Schlichting <hannosch at hannosch.eu>

> To summarize the feedback from the European time zone, I think that the
> proposal in general meets the favor of everyone.
> The controversial issue is the exact version number to use for the
> release. There seems to be broad support for freeing the current Plone
> trunk from a version designator and release a 4.0 release with the
> envisioned scope of this proposal instead.

I really agree with the concern about 3.5 but I also agree with the
problem of the expectations we've developed about what Plone 4 will be.
I also *really* like the idea of having a release series where we can
introduce changes of a level of risk *in between* that which is
appropriate for a stable release and that which is appropriate for a
major release.

IOW, I like the idea of a set of Plone releases that will grow towards
"the feature set formerly known as Plone 4" in incremental, somewhat
disruptive releases that are still appropriate for wide usage.  Consider
that we release all the "yes" items from Hanno's spreadsheet as Plone 4.
Can we then add the "maybe"'s in 4.1?  Or will those changes then be
considered too unstable for inclusion in an already released major

Sorry if I'm resurrecting an already fairly resolved debate.  None of
the concerns I raise here are enough to vote -1 one calling it 4.0.  But
if enough people feel as I do here, maybe we should discuss a little
further.  What about plone 3.9?

> If I do not get a strong signal or message otherwise, consider this
> proposal changed in this regard.

> Hanno Schlichting wrote:
>> Hi.
>> While everyone is waiting for Plone 4 and its rather long timeline, some
>> people have been thinking about how to bridge the gap between the
>> current stable 3.x releases and the future.
>> The general idea that seems to have met some consensus is to go for a
>> Plone 3.5 release up next. We'd skip any 3.4 release and go for a 3.5
>> that is similar in spirit to the Plone 2.5 release. It tries to both
>> refresh some of our technical underpinnings in addition to some more
>> intrusive feature changes we didn't allow ourselves in the 3.x series so
>> far.
>> In order to frame the scope of such a release I made a listing of some
>> of the potential features for such a release at
>> http://spreadsheets.google.com/pub?key=rFHYANxtkRfGYchi1QuS5dA. The list
>> is both non-exclusive and non-binding in the recommendations.
>> The envisioned timeline for a Plone 3.5 release would be to aim for a
>> final release either by the time of the conference or by the end of this
>> year, giving us six months or a bit more for it. By aiming for an
>> after-summer beta deadline we will have a chance of leveraging some
>> Google Summer of Code contributions for such a release.
>> When it comes to the official personal involved in such a new major
>> release, I'd like to suggest a slight deviation on our process. As many
>> to all of the features changes in question for the 3.5 release have so
>> far been in the scope of the 4.0 release, I'd suggest to appoint the
>> entire 4.0 framework team to be the official team for 3.5 as well. This
>> forces them to get involved with the process in a more defined and clear
>> way now.

I'm willing.

>> On the side of the release manager, Wichert has signaled that his
>> workload as a freelancer will not allow him to take over the shepherding
>> of a new major release. We do however have with Eric Steele of PSU fame
>> a well-known interested candidate for the position.
>> This is only a proposal that needs community feedback and encouragement
>> at this point to make it into an official roadmap. The next steps are to
>> have an open discussion about this for the next one to two weeks. If it
>> meets general favor, we will appoint the new/old framework team and let
>> them recommend a release manager to the Foundation board for official
>> nomination.

BLOBs: Has the backups/repozo story been sufficiently worked out?

Python 2.5: I'd like to see this one in 3.5.  Being "stuck" on "such an
old version" of Python seems to have psychological/perceptual effects in
the community and to those looking at Plone from the outside.  Moving to
2.5 now might help with that issue while at the same time priming the
pump for the development community to begin updating their code to more
modern Pythonisms while still being less painful than 2.6/2.7.  IOW, I
think it's a good stepping stone.

Quickinstaller: I think ripping it out in 3.5 would be a bad idea, to
disruptive in the larger add-on ecosystem.  I know I have several
clients for whom this would mean I couldn't upgrade them to 3.5 since
they still depend on add-ons that use Extensions/install.py.  How about
instead switching to a new GS based UI and officially deprecating the QI
thus paving the way for full removal in 4?

plone.folder: +10.  Many of my clients have been bitten by poor ordered
folder scaling.  In fact, I've gotten more clients that way than can be


More information about the Framework-Team mailing list