[Framework-Team] Re: Plone 4 dependencies

[David Glick]

On May 27, 2009, at 1:47 PM, Matthew Wilkes wrote:
> On 26 May 2009, at 10:59, Hanno Schlichting wrote:
>
>> I think someone has to try and see what kind of changes are acutally
>> required to make a current Plone 3.3rc3 run on Zope 2.12 or even  
>> better
>> a real client side with a collection of add-ons.
>
> I doubt it's very hard, a concerted effort by me and Sidnei at the  
> last Summer of Code summit left us with Plone trunk working on Zope  
> trunk, and that was only a few weeks after the conference.  Zope  
> really was where most of the changes needed to be, I do think  
> targeting 4.0 to Zope 2.12 is feasible and proper.


+1.  The nice thing is that the question of what changes need to  
happen to support Zope 2.12 and CMF 2.2 is not some big unknown.  We  
already have changesets that take care of the vast majority of the  
issues, thanks to the work Hanno, Matthew, Laurence and others have  
been doing on Plone trunk over the past year.

That's not to say that it wouldn't take some work.  The desirable  
changesets that take care of Python 2.6 compatibility, removing old  
Zope 2-style interfaces, and miscellaneous non-risky improvements are  
mixed in with things like moving the default content views to be  
browser views in ATContentTypes instead of skin layer templates in  
CMFPlone, which probably need some more discussion and may or may not  
be wanted in Plone 4.

My gut feeling is that we probably should target Zope 2.12 and CMF  
2.2, and probably want a majority of the changes from Plone trunk, but  
will want to opt out of some that are overly ambitious or ripping out  
things that we don't have adequate replacements for yet.  So I think  
it's probably time to create a new copy of the 3.3 branch for Plone 4,  
and start selectively merging changes from trunk.

(Yes, this means that developers will have to start merging changes to  
2 different branches aside from where they originally patched a bug.   
This is an unfortunate side effect of us working so far ahead.  We'll  
also have to consider what happens with the version numbers of the  
various plone.* packages which Hanno has been calling 2.x for use with  
Plone trunk...in most cases the changes are probably fine for Plone 4  
and we can just keep using 2.x, but if there is a package with some  
changes on trunk that we don't want, we'll have to make a 2.x branch  
without the undesirable change and move that package's trunk up to 3.x)

Eric Steele, you should feel free to jump in and start being  
benevolently dictatorial. :)

Raphael raised a question about the consequences of backwards- 
incompatible changes for add-on developers.  Switching to a newer Zope  
and CMF will indeed probably have some consequences.  But this is a  
major version bump of Plone, so I think it's okay if some things  
change; this is probably our best opportunity to rip out some old  
cruft.  We do need to do a better job than we have in the past of  
documenting changes in a form that is useful to add-on developers  
trying to figure out why their product broke or what the new way to do  
something is.  Creating a list of these changes is a task that should  
be done as changesets are reviewed and merged from trunk.

David Glick
Web Developer
ONE/Northwest

New tools and strategies for engaging people in protecting the  
environment

http://www.onenw.org
davidglick at onenw.org
work: (206) 286-1235 x32
mobile: (206) 679-3833

Subscribe to ONEList, our email newsletter!
Practical advice for effective online engagement
http://www.onenw.org/full_signup