Re: [Framework-Team] Plone 3.5

[Alexander Limi]

On Tue, 05 May 2009 13:26:37 -0700, Alec Mitchell  
 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


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Plone-developers] [Framework-Team] Plone 3.5

[Helge Tesdal]

On 5. mai. 2009, at 22:26, Alec Mitchell wrote:


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.


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


--
___

 Helge Tesdal · Senior Developer, Jarn · www.jarn.com

   Plone Solutions, Development, Hosting and Support
___




___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Plone-developers] [Framework-Team] Plone 3.5

[Alec Mitchell]

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.

Alec

On Tue, May 5, 2009 at 5:23 AM, 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
>> 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-developers mailing list
> plone-develop...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Plone 3.5

[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


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Plone 3.5

[Ricardo Alves]

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 
Eurotux  



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Plone 3.5

[Helge Tesdal]

I'm leaning towards naming the new intermediate release Plone 4 rather  
than Plone 3.5, and change what we previously thought of as Plone 4 to  
Plone 5 or Plone Future (until it becomes close enough in time to give  
it a version number).


Plone 3 has been stable and a safe choice, and jumping to 3.5 with  
bigger changes can only confuse people.


--
___

 Helge Tesdal · Senior Developer, Jarn · www.jarn.com

   Plone Solutions, Development, Hosting and Support
___




___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Plone-docs] [Framework-Team] Plone 3.5

[JoAnna Springsteen]

(sorry if you get this twice)

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

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Re: [Framework-Team] Plone 3.5

[Tom Lazar]

for the record, i think this is a great idea.

this will also take some weight off of the 4release, since some of its  
low-risk components will have had some real-world usage by then.


also, it should make migrations from 3.x to 4.x easier, i could imagine.

i'm also more than fine with eric as 3.5 release manager. thanks for  
volunteering, eric!


just my €0.02,

tom

On 05.05.2009, at 13:44, 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.

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.

Cheers,
Hanno


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team




___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

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


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)
- We maintained 3.x as officially supported

Matt

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

[Framework-Team] Plone 3.5

[Hanno Schlichting]

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.

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.

Cheers,
Hanno


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team