[Plone-developers] [Framework-Team] Plone 3.5
apm13 at columbia.edu
Tue May 5 20:26:37 UTC 2009
I agree with what appears to be majority opinion here – that this
release should be called Plone 4.0. Whatever expectations people
might already have regarding Plone 4.0 can be easily managed.
I'd like to stand up for "my" release a little, since people seem to
be implying it was some sort of expectations/compatibility disaster.
Plone 2.5 introduced some new infrastructure and officially deprecated
a number of old APIs, scripts and templates, but it maintained
compatibility for all of those. The only exception that I'm aware of
is the introduction of PlonePAS, which theoretically offered API
compatibility but failed in that regard with some 3rd-party add-ons.
The scope of 2.5 was well defined, and highly constrained (in fact,
Plone's official deprecation/compatibility policy was established as a
part of the 2.5 release). The numbering jump may not have been ideal,
but calling that release 3.0, when there were almost no outwardly
visible changes (aside from deprecation warnings in your logs), would
have also been a blunder, IMO.
If you want to pinpoint a release that broke expectations with regard
to compatibility, Plone 2.1 is a far better example. There were a
huge number of incompatibilities and migration issues between 2.0 and
2.1. The transition to ATCT alone was worth a major revision, never
mind the numerous API and UI changes and configuration options
removed/disabled (some of which were thankfully put back in place in
2.5). If anything, Plone 2.5 began to establish a contract of major
release compatibility that had been entirely destroyed with the 2.0 ->
2.1 transition. Plone 2.5 wasn't perfect, but I find it hard to
imagine it as the expectations nightmare people are portraying here.
On Tue, May 5, 2009 at 5:23 AM, Matthew Wilkes <matt at matthewwilkes.name> 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 special-case major release was
> quite nasty, it confused people about what was a major release and
> what isn't. Also, we've made a commitment to 3.x being stable, I
> think we should keep to it. However, it would be good to open the new
> features to a wider audience ASAP.
> I'd be -1 if it hurts our users by discontinuing a stable platform in
> favour of a half-way house. If we keep Plone 3.x as fully supported
> and this being something for early adopters and dare-devils, then I'd
> be +0. I'd be +1 if this was distinction was made explicit in the name.
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> Plone-developers mailing list
> Plone-developers at lists.sourceforge.net
More information about the Framework-Team