Re: [Framework-Team] Plone 3.5

[Matthew Wilkes]

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
> far.

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.

Matt


------------------------------------------------------------------------------
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-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

[Martin Aspeli]

Matthew Wilkes wrote:

> 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 idea is *not* to make a release for dare-devils and early adopters.
That'd be a 4.0 alpha or something.

The idea is to introduce some features that are low/medium risk and
possible to integrate *now*, but which are too invasive for the strict
3.x series criteria we've had until now.

The idea is also to catch up with our platforms (Zope 2, Zope 3, CMF) as
we're starting to look a bit out of date on Zope 2.10 + Zope 3.3 + CMF 2.1.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


------------------------------------------------------------------------------
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-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

[JoAnna Springsteen]

> The idea is also to catch up with our platforms (Zope 2, Zope 3, CMF) as
> we're starting to look a bit out of date on Zope 2.10 + Zope 3.3 + CMF 2.1.

What's the significance of 3.5? Why can't this catch up be done in
increments? 3.4 then 3.5 then 3.6?

My worry here is that catching up will mean a repeat of 2.5. Not to
mention if we are changing this much stuff on a platform level that it
won't get documented. The framework team would have to be responsible
for documenting these changes as the documentation team just does not
have the man power. Sure, we made the 3.3 release w/ documentation and
that was relatively small stuff. If you go for a bigger release under
the 3.x series we're going to end up back where we started....New
technologies and no documentation. This will further the idea that
being a Plone developer is only for elite code jockeys. That's not
really something we want to reinforce, is it?

I gotta tell ya, this idea makes me really really nervous. I thought
the whole point of 3.x was to be stable and not repeat past mistakes?
I'm all for getting closer to 4.x but we need to do it in bite sized
steps, not all at once.

J.

------------------------------------------------------------------------------
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-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

[Martin Aspeli]

JoAnna Springsteen wrote:
>> The idea is also to catch up with our platforms (Zope 2, Zope 3, CMF) as
>> we're starting to look a bit out of date on Zope 2.10 + Zope 3.3 + CMF 2.1.
>
> What's the significance of 3.5? Why can't this catch up be done in
> increments? 3.4 then 3.5 then 3.6?

Because upgrading Zope versions and some of the other changes are too
big for the Plone 3.x stability promise.

> My worry here is that catching up will mean a repeat of 2.5.

What does that mean?

> Not to mention if we are changing this much stuff on a platform level that it
> won't get documented. The framework team would have to be responsible
> for documenting these changes as the documentation team just does not
> have the man power. Sure, we made the 3.3 release w/ documentation and
> that was relatively small stuff. If you go for a bigger release under
> the 3.x series we're going to end up back where we started....New
> technologies and no documentation. This will further the idea that
> being a Plone developer is only for elite code jockeys. That's not
> really something we want to reinforce, is it?

This sounds like a false dichotomy to me, and basically an argument for
doing *no* innovation, which is surely not what you meant.

The framework team wouldn't need to document anything. PLIP implementers
would be asked to provide documentation. And many of the features are
end-user things that probably the docs team could help with.

> I gotta tell ya, this idea makes me really really nervous. I thought
> the whole point of 3.x was to be stable and not repeat past mistakes?
> I'm all for getting closer to 4.x but we need to do it in bite sized
> steps, not all at once.

I think you may have missed the point here...

Going straight to 4.0/trunk would be all-at-once. The 3.5 proposal is
about creating a mid-point between what we have now (3.x) and that
(4.0), that gives us some of the platform changes that will be necessary
going forward, some of the features that we can deliver now rather than
waiting 12-18 months, but not all the game-changing stuff like Deco or
making Archetypes optional.

... so pretty much what you asked for. :)

Martin


--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


------------------------------------------------------------------------------
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-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

[Ricardo Alves-2]

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.

-1 on skipping 3.4. It will mostly bring more confusion. People will ask
why, and most, manly newbies and outsiders who don't understand the
complexity of the Plone stack, won't understand the rationale behind it.
Also people will expect a 3.5 release to keep the promise of stability
of the 3.x series.

>
> 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.

It would be great to have such improvements before Plone 4. But I think
most of these features, specially the ones tagged as "low risc" can, and
should, be included in the 3.x series (3.4, 3.5, ...), without breaking
backwards compatibility. Although, some may need special attention in
regard to bbb.

I don't think there is a good solution here, but it will be less painful
if we don't mess up with version numbering.


Just my 2 cents :)


Ricardo

--
Ricardo Alves <[hidden email]>
Eurotux <http://www.eurotux.com>


------------------------------------------------------------------------------
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-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

[Raphael Ritz]

[Do we really need to discuss this on three lists?]

Martin Aspeli wrote:
> JoAnna Springsteen wrote:
>>> The idea is also to catch up with our platforms (Zope 2, Zope 3, CMF) as
>>> we're starting to look a bit out of date on Zope 2.10 + Zope 3.3 + CMF 2.1.
>> What's the significance of 3.5? Why can't this catch up be done in
>> increments? 3.4 then 3.5 then 3.6?
>
> Because upgrading Zope versions and some of the other changes are too
> big for the Plone 3.x stability promise.

Do we know that for sure already?
Do we know how far we could get with some temporary
module aliases to take care of stuff that has been
moved around?

>
>> My worry here is that catching up will mean a repeat of 2.5.
>
> What does that mean?
>

That we confused people to now end ...


As I understand the current discussion the general idea
is most welcome. People are concerned of staying in line
with our long-term promises and it seems to me that this
almost exclusively boils down to a naming issue.

Frankly speaking I would have no problem calling the proposed
intermediate release Plone 4 and not to assign a version number
to current trunk at all. AFAICS the current co-notation of
Plone 4 being the all-new, all-shiny next generation of Plone
is merely a project internal that we can redefine without
much of a problem but doing it the other way around because
we consider sneaking in a major release before the next major
release that some got used to think of being Plone 4
carries the risk of creating confusion and distrust where we
can't control it.

Raphael


------------------------------------------------------------------------------
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-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

[Martin Aspeli]

Raphael Ritz wrote:
> [Do we really need to discuss this on three lists?]

Think of the fun and excitement of all those new emails in your inbox...
(no, we don't, but it's too late now)

> Martin Aspeli wrote:
>> JoAnna Springsteen wrote:
>>>> The idea is also to catch up with our platforms (Zope 2, Zope 3, CMF) as
>>>> we're starting to look a bit out of date on Zope 2.10 + Zope 3.3 + CMF 2.1.
>>> What's the significance of 3.5? Why can't this catch up be done in
>>> increments? 3.4 then 3.5 then 3.6?
>> Because upgrading Zope versions and some of the other changes are too
>> big for the Plone 3.x stability promise.
>
> Do we know that for sure already?
> Do we know how far we could get with some temporary
> module aliases to take care of stuff that has been
> moved around?

This is a good point. But it feels risky nonetheless. It was definitely
something we held up as an example of something we wouldn't do in a
minor release.

It almost certainly will break some third party add-ons, but hopefully
not any well-behaved ones. I guess only time will tell.

Some of the '2009' features also involve changing templates in a way
that could cause some breakage to particular customisations as well.

> As I understand the current discussion the general idea
> is most welcome. People are concerned of staying in line
> with our long-term promises and it seems to me that this
> almost exclusively boils down to a naming issue.

Yep. I think this is a healthy debate, and I'm personally only +0.25 on
the 3.5 name.

I'm a bit worried that in the past, we've tried to accompany the .0
releases with a bit more fanfare, e.g. on CMSWatch, Digg, and so on.
This release probably wouldn't warrant that type of release management.
But that's not to say we can't tell a good story around a less ambitious
4.0 release and talk up a 5.0 later.

> Frankly speaking I would have no problem calling the proposed
> intermediate release Plone 4 and not to assign a version number
> to current trunk at all. AFAICS the current co-notation of
> Plone 4 being the all-new, all-shiny next generation of Plone
> is merely a project internal that we can redefine without
> much of a problem but doing it the other way around because
> we consider sneaking in a major release before the next major
> release that some got used to think of being Plone 4
> carries the risk of creating confusion and distrust where we
> can't control it.

That's a really long sentence, but I think I agree... :)

Martin


--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


------------------------------------------------------------------------------
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-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

[Carsten Senger-3]

Hi Martin,

Martin Aspeli schrieb:

> Matthew Wilkes wrote:
>
>> 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 idea is *not* to make a release for dare-devils and early adopters.
> That'd be a 4.0 alpha or something.
>
> The idea is to introduce some features that are low/medium risk and
> possible to integrate *now*, but which are too invasive for the strict
> 3.x series criteria we've had until now.

Then we should name it 4.0. From the users perspective it makes not
sense to name something 3.5 that breaks the "3.x will stay backward
compatible" rule to introduce something that is "incompatible, but not
as incompatible as Plone 4". Even if we are used to the name Plone 4.

> The idea is also to catch up with our platforms (Zope 2, Zope 3, CMF) as
> we're starting to look a bit out of date on Zope 2.10 + Zope 3.3 + CMF 2.1.

That's a good thing for developers that are relatively near to core
development. For the rest backward incompatibility is a major pain.
Incompatible Add-On combinations, not up-to-date documentation, a long
update cycle for some important products, all nice things a Plone user
can think of.

..Carsten

------------------------------------------------------------------------------
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-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

[Alexander Limi]

On Tue, 05 May 2009 13:26:37 -0700, Alec Mitchell  
<[hidden email]> wrote:

> If you want to pinpoint a release that broke expectations with regard
> to compatibility, Plone 2.1 is a far better example.

Just to make sure history is represented correctly here — Alec is  
absolutely right.

Plone 2.5 was a well-managed release, 2.1 was a disaster (from a release  
management perspective). Luckily, we've had incredible release managers  
and good processes from Alec going forward — and we're extremely fortunate  
in that regard.

--
Alexander Limi · http://limi.net


------------------------------------------------------------------------------
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-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs

[Erik Rose]

> I don't consider it a disaster. To me it's more about the community  
> learning from mistakes, identifying areas of improvement and getting  
> better by each release. If we were more happy with Plone 2.5 than 3,  
> we would have a real problem. :)

Actually, 2.5 had a lot going for it. We still have several  
integrators who prefer 2.5 for its buildoutless installation and  
development, simpler theming, and lack of (to them) arbitrary  
divisions like portal_skins/portal_view_customizations that arise from  
phasing in the component architecture. Personally, I like 3 for a lot  
of other reasons, but I can relate to their pain points and look  
forward to spending my FWT votes to try to make things simpler and  
more consistent (which is hopefully the way we're going anyway).

Erik Rose
weblion.psu.edu

------------------------------------------------------------------------------
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-docs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-docs