[Framework-Team] Re: Plone 3.5
optilude+lists at gmail.com
Tue May 5 12:20:48 UTC 2009
Matthew Wilkes wrote:
> On 5 May 2009, at 12:44, Hanno Schlichting wrote:
>> 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
> Why skip 3.4? That Plone 2.5 was a major release was quite nasty, it
> confused people about what was a major release and what isn't. We've
> made a commitment to 3.x being stable, I think we should keep to it.
> Releasing a Plone 3.5 would confuse the matter.
It's tricky, and we discussed this back and forth a few times before
this proposal was formulated. I still think the version numbering is up
The thinking is basically:
- We'd like to move to ZODB 3.9 (blobs), Zope 2.11 (Zope 3.4), and
possibly CMF 2.2 (trunk). Those changes are too big for the stability
promise in 3.x.
Note that there's a certain imperative in this. In particular, I *hope*
that we can get unofficial Python 2.5 support for Zope 2.11. Zope 3.3 is
also becoming kind of painful as a platform. And blobs are way overdue.
- We'd like to integrate some new features. Not critical stuff that
couldn't be done with surgical add-ons, but nice-to-haves that will
improve the experience for a lot of people.
- However, to end users, this is still incremental stuff - not really
enough for the kind of marketing push we'd like to attach to a
- The term "Plone 4" is already out there meaning trunk, deco,
deliverance, dexterity, unified types, tiles, and all that jazz. If we
suddenly now start talking about a much more incremental "Plone 4",
we'll cause a lot of confusion.
So, 3.5 is a compromise. The skipping of 3.4 actually helps back the
story up. We could try something else, like Plone 2009, but I'm pretty
sure we'd regret that in 2010 for one reason or another. And PyPI
wouldn't like it.
> However, it would be interesting to open the new features to a wider
> audience ASAP. I'd be in favour of this if:
> - It wasn't called Plone 3.x or 4.x (Dunno what though)
Yeah, thanks for helping. :p
> - We maintained 3.x as officially supported
I think that'd be the case under the "two supported versions" policy.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Framework-Team