Re: [Framework-Team] Re: Plone 4 dependencies
On 01.06.2009, at 21:42, Hanno Schlichting wrote: I think we can move all the admin-UI stuff like preference screens, folder_copy, object_rename and author pages and the like from CMFPlone to browser views in Plone 4, as these tend not to be customized that often. +1 also, those views contain more functionality than the ones mentioned below and thus the benefit of migrating those rather sooner than later is a lot bigger. IMHO those changes are definitely plone 4 material. cheers, tom I wouldn't want to see document_view, folder_listing and the more commonly customized templates to be changed in Plone 4, though. Changing these will break lots of customizations out there and I only want to do that once we have figured out the complete story for TTW editing and new-style default theming. As long as we have Archetypes and any AT-based add-on, we won't be able to ditch portal_skins anyways. It's whole widget machinery and base_* are too tightly based on nested skin layers and lots of magic. 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
[Framework-Team] Re: Plone 4 dependencies
David Glick wrote: 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) My main reason to call all these trunk version 2.x was to allow for many more minor-feature-upgrades aka. 1.2, 1.3, ... to happen for these packages before the grand-overhaul-breaking-backwards-compatibility thing. I think we should branch of the last 1.x branch of a package to a new 1.x+1 branch for the packages where we need to do this. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 4 dependencies
Matthew Wilkes wrote: Perhaps the question we should be asking is, What do we want the new features for Plone 5 to be?. I think moving to browser views for default templates would be useful, if not just so it unifies our customisation story. On the concrete example given, quite high-up on my list of wishlist features for Plone 4 would be ditching portal_skins and having a layer-aware analogue for browser views, with an exporter. TTW editing is sorely missing in 3.x, and I think it's a pain point. +1 for it being a pain point. But ;) I think we can move all the admin-UI stuff like preference screens, folder_copy, object_rename and author pages and the like from CMFPlone to browser views in Plone 4, as these tend not to be customized that often. I wouldn't want to see document_view, folder_listing and the more commonly customized templates to be changed in Plone 4, though. Changing these will break lots of customizations out there and I only want to do that once we have figured out the complete story for TTW editing and new-style default theming. As long as we have Archetypes and any AT-based add-on, we won't be able to ditch portal_skins anyways. It's whole widget machinery and base_* are too tightly based on nested skin layers and lots of magic. Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 4 dependencies
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
Re: [Framework-Team] Re: Plone 4 dependencies
On 30 May 2009, at 22:23, David Glick wrote: 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. Perhaps the question we should be asking is, What do we want the new features for Plone 5 to be?. I think moving to browser views for default templates would be useful, if not just so it unifies our customisation story. We've got lots of new things that we're all itching to use, but we need to balance that with making the upgrade from 3-4-5 as smooth as possible for our integrators. On the concrete example given, quite high-up on my list of wishlist features for Plone 4 would be ditching portal_skins and having a layer- aware analogue for browser views, with an exporter. TTW editing is sorely missing in 3.x, and I think it's a pain point. Matt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 4 dependencies
On May 30, 2009, at 3:01 PM, Matthew Wilkes wrote: On 30 May 2009, at 22:23, David Glick wrote: 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. Perhaps the question we should be asking is, What do we want the new features for Plone 5 to be?. I think moving to browser views for default templates would be useful, if not just so it unifies our customisation story. We've got lots of new things that we're all itching to use, but we need to balance that with making the upgrade from 3-4-5 as smooth as possible for our integrators. On the concrete example given, quite high-up on my list of wishlist features for Plone 4 would be ditching portal_skins and having a layer-aware analogue for browser views, with an exporter. TTW editing is sorely missing in 3.x, and I think it's a pain point. I absolutely agree that we need to do this. (See my blog post [1] from February and the follow-up e-mail conversation [2] on how I think we should go about it.) Given that the goal of the Plone 4 release is to incorporate fairly low-risk things that have already been built, though, I'm not sure this is an appropriate goal for Plone 4. And while I agree that in the end view templates should be browser views, I don't want to make that switch until we have a complete TTW editing story for browser views. I think this is the point you were making as well. If we start actually working on this and make rapid progress, and have a solid migration story, I'm willing to reconsider for Plone 4. [1] http://david.wglick.org/2009/report-from-the-berlinale-sprint-how-we-can-fix-the-plone-skin-situation/ [2] http://n2.nabble.com/Re:-report-from-the-Berlinale-sprint:-how-we-can-fix-the-Plone-skin-situation-td2376181.html 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
[Framework-Team] Re: Plone 4 dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Raphael Ritz wrote: Wichert Akkerman wrote: I seem to remember the plan was to target Plone 4 for CMF 2.2 and Zope 2.11, but as you can see below that does not appear to be possible. So that means Zope 2.12 instead, right? Do we have an estimate of what that implies on our side? Generally speaking, I'm a bit uncomfortable with jumping from Zope 2.10.x to 2.12.x as this will reduce the chances of reacting to deprecation warnings which is of particular importance for all our add-on developers. I'm afraid we'll see lots of broken add-ons without prior warnings. If there is nothing we can do about this (and it seems so) we could still consider to have Plone 3.x move to Zope 2.11 with 3.4 or 3.5. Just thinking out loud (and without knowing myself how much differences there are between Zope 2.10 and 12 that do affect us) ... An outsider's take: I would strongly urge that a release-by-year-end Plone4 use Zope 2.12. There is no compelling technical reason to hold off, and plenty of time to test and iron out any issues. Staying up-to-date gets you a migration path to a Python version (2.6) which will be supported for a reasonable time frame (2.4 is effectively out of support now; 2.5 is at the end of its support life). It will also allow Plone to use the fully eggified Zope, and rip out lots of workarounds (fake eggs, anyone). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKHaD0+gerLs4ltQ4RAphjAKCrWddVIMNgM1E9kLQfb8xe7lMdsgCgivEI QbaGWkFEAB44GxB43EN05hM= =goDC -END PGP SIGNATURE- ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 4 dependencies
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. Matt ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: Plone 4 dependencies
On Wed, May 27, 2009 at 22:47, Matthew Wilkes matt...@matthewwilkes.co.ukwrote: 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 Andreas ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: Plone 4 dependencies
Wichert Akkerman wrote: I seem to remember the plan was to target Plone 4 for CMF 2.2 and Zope 2.11, but as you can see below that does not appear to be possible. So that means Zope 2.12 instead, right? Do we have an estimate of what that implies on our side? Generally speaking, I'm a bit uncomfortable with jumping from Zope 2.10.x to 2.12.x as this will reduce the chances of reacting to deprecation warnings which is of particular importance for all our add-on developers. I'm afraid we'll see lots of broken add-ons without prior warnings. If there is nothing we can do about this (and it seems so) we could still consider to have Plone 3.x move to Zope 2.11 with 3.4 or 3.5. Just thinking out loud (and without knowing myself how much differences there are between Zope 2.10 and 12 that do affect us) ... Raphael Wichert. - Forwarded message from Jens Vagelpohl j...@dataflake.org - From: Jens Vagelpohl j...@dataflake.org To: Zope-CMF List zope-...@zope.org Subject: Re: [Zope-CMF] Zope dependency Message-Id: 7d23df64-b4dc-4c8e-8a51-188e8b34a...@dataflake.org Date: Tue, 26 May 2009 10:57:08 +0200 X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.2.3 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 26, 2009, at 10:21 , Wichert Akkerman wrote: Previously Jens Vagelpohl wrote: The CMF eggs, even on trunk, still advertise compatibility with Zope 2.10. I believe we had agreed to target Zope 2.12 with trunk - please correct me if that's wrong. If we do want Zope 2.12 I would like to go through before the first CMF 2.2 beta and do the following: - adjust all setup.py files to show the Zope2 egg as dependency, which will imply the Zope2 = 2.12dev dependency - go through and delete all BBB code for Zope versions earlier than 2.12 If anyone thinks that's a bad idea please speak up. I think we are targetting Plone 4 at CMF 2.2 and Zope 2.11 at the moment, so that would be bad for us. I'm guessing you are not aware that there already is a hard dependency in CMFDefault. In essence, I would not be setting a new policy, I would document the current situation. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkobruQACgkQRAx5nvEhZLJadACfa9oLhpOAluaPN4QNqGf8UW26 4V8AmwSNnABEZwAQwpq1XddErphVHW0o =o1v4 -END PGP SIGNATURE- ___ Zope-CMF maillist - zope-...@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests - End forwarded message - ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
