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
davidgl...@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
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
