Re: [Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 22 Dec 2005, at 17:09, Martin Aspeli wrote: Jens Vagelpohl wrote: I think this brings up the need for a slightly more formalized planning and release process. Given the requisite backing by at least the main developers (meaning their agreement that they would actually use such a thing) I'd like to set up a release plan page on zope.org that explains a bit more what the goals for each major release are and which contains timing information as well. The Plone roadmap page at http://plone.org/roadmap (plone.org seems down currently) does a nice job in that regard. Tres said: I agree we need such a document, and already owe you some words around the topic. I'll work on setting up a back-channel conversation about it. You can of course use the PloneSoftwareCenter :-) Complete overkill, sorry. We're dealing with one project here, and for starters we need a simple document, and then go from there. Matter of fact a simple Wiki would be good, probably right underneath www.zope.org/Products/CMF. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Jens Vagelpohl wrote: I think this brings up the need for a slightly more formalized planning and release process. Given the requisite backing by at least the main developers (meaning their agreement that they would actually use such a thing) I'd like to set up a release plan page on zope.org that explains a bit more what the goals for each major release are and which contains timing information as well. The Plone roadmap page at http://plone.org/roadmap (plone.org seems down currently) does a nice job in that regard. Tres said: I agree we need such a document, and already owe you some words around the topic. I'll work on setting up a back-channel conversation about it. You can of course use the PloneSoftwareCenter :-) Either, you can create a project on plone.org/products and use the features there, or you can set up a standard Plone 2.1 site and install PloneSoftwareCenter (note that you currently need the 2.1-integration branch; we're working on getting a real release out) and its dependencies (ArchAddOn, ExternalStorage optional). Here, you can get the same roadmap features for any project. Martin -- (muted) ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Jens Vagelpohl wrote: On 20 Dec 2005, at 23:32, yuppie wrote: After reading the thread you mention, which isn't all that clear when it comes to outlining what the consequences of some of these code changes are, I'm confused. I think I can boil it down to one question: What is the use of the CMF 1.6 branch if it is not compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and possibly not even 2.2 since that's only a few months down the road? I don't quite understand the distinction between compatible with products written for Plone 2.1 but not with Plone 2.1, I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. That might have changed over time, but the code never reflected that change. Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6-compatible then? The new way (exemplified by the way CMFCore itself registers 'Factory-based' type information) is: - make the class provide ITypeInformation (either directly or through ZCML), - five:registerClass the class (this makes it available in Products.meta_types and for IFAwareObjectManager, which the portal_types ZMI add menu uses), - register an IAdding for it, usually coded in browser/. Using the base class provided by CMFCore it's only a few lines. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 21 Dec 2005, at 11:14, Florent Guillaume wrote: Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6- compatible then? The new way (exemplified by the way CMFCore itself registers 'Factory-based' type information) is: - make the class provide ITypeInformation (either directly or through ZCML), - five:registerClass the class (this makes it available in Products.meta_types and for IFAwareObjectManager, which the portal_types ZMI add menu uses), - register an IAdding for it, usually coded in browser/. Using the base class provided by CMFCore it's only a few lines. Thanks a lot Florent, I assume Martin can go off and do his magic with that description. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Well now I'm *completely* confused. grin - Rocky Alexander Limi wrote: On Wed, 21 Dec 2005 00:32:02 +0100, yuppie [EMAIL PROTECTED] wrote: AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. Just a terminology correction here, the next version of Plone is 2.5, not 2.2 - we changed our version policy a while back: http://plone.org/products/plone/roadmap/114 http://plone.org/roadmap (Not that important for this discussion, but just a heads-up so you non-Plone people don't get confused about 2.2 vs. 2.5 when we talk about it later. :) -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 21 Dec 2005, at 12:06, Raphael Ritz wrote: Starting to look into this myself I just wasted a couple of minutes because of my outdated setup (I had a plain Zope-2.8.4-final release) Looking at INSTALL.txt from the CMF-1.6 bundle I found Requirements - Zope 2.8.1 or later ... so I thought I'm on the safe side but digging deeper one actually sees in GenericSetup.DEPENDENCIES.txt: Yes, this will need some cleanup before the first beta. Instead of upgrading Five, I thought I better get Zope-2.9.0b1 which wanted me to upgrade my Python to 2.4.2. I only have a 2.4.1 around with I took and now everything seems OK. You can just download and put Five 1.2b into your INSTANCE_HOME, it will be loaded in preference to the stuff in the SOFTWARE_HOME jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Rocky Burt wrote: Raphael Ritz wrote: Looking at INSTALL.txt from the CMF-1.6 bundle I found Requirements - Zope 2.8.1 or later ... so I thought I'm on the safe side but digging deeper one actually sees in GenericSetup.DEPENDENCIES.txt: Zope = 2.8.5 Five = 1.2 So I got a Zope-2.8.5-final only to realize later that this ships with Five-1.0.2 :-( Your best bet is to install Zope 2.8.5-final and then install Five 1.2b (in your instance home Products dir). Not sure what other troubles Zope 2.9b1 would bring to the table here. I'm currently working on having CPS work with CMF 1.6 branch and Zope 2.9 branch. I've had a few fixes to make already, today most things should work. A few more may come when I test deeper. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Hi, The following checkin on the 1.6 branch, which looks like a pure cleanup item, completely breaks Plone 2.1 and up on CMF 1.6. I assume that was not the intention. http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py? rev=40364r1=40360r2=40364 Do you know how it breaks Plone, exactly? What was this checkin intended to do? Martin -- (muted) ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 20 Dec 2005, at 13:10, Martin Aspeli wrote: Hi, The following checkin on the 1.6 branch, which looks like a pure cleanup item, completely breaks Plone 2.1 and up on CMF 1.6. I assume that was not the intention. http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py? rev=40364r1=40360r2=40364 Do you know how it breaks Plone, exactly? What was this checkin intended to do? I don't know what the checkin was supposed to do apart from a cleanup, that's why I am asking Yvo. That CMFDynamicViewFTI doohickey (no idea what that is, really, but Plone needs it for some reason) tries to import typeClasses from CMFCore.TypesTool and add information about itself to it. See fti.py module. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Hi Jens! Jens Vagelpohl wrote: The following checkin on the 1.6 branch, which looks like a pure cleanup item, completely breaks Plone 2.1 and up on CMF 1.6. I assume that was not the intention. http://svn.zope.org/CMF/branches/1.6/CMFCore/TypesTool.py?rev=40364r1=40360r2=40364 I'm in the specific situation where I have an existing Plohn 2.1 site and I want to use PAS. The latest PAS depends in a current GenericSetup, so I am trying to move the Plone site onto the current CMF 1.6 branch. Due to the change above this is not possible. Question: If we claim CMF 1.5 compatibility, do you mind reverting this checkin? The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way. I fixed the new machinery because - most code used already the new machinery (and I thought that was Rob's intention) - this doesn't break many products I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 20 Dec 2005, at 19:53, yuppie wrote: The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way. I fixed the new machinery because - most code used already the new machinery (and I thought that was Rob's intention) - this doesn't break many products I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin. Like what exactly? With all due respect, the 1.6 branch should *not* break stuff that works find on 1.5. The specific goal for 1.6 was to be 1.5 plus GenericSetup so that it stays 1.5-compatible. This change has nothing to do with GenericSetup from all I can tell. Please don't just say OK, change it back if you want, but there may be traps elsewhere. I do not know what all needs to be changed. I'll be happy to do it, but I need to know what else is involved. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Jens Vagelpohl wrote: On 20 Dec 2005, at 19:53, yuppie wrote: The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way. I fixed the new machinery because - most code used already the new machinery (and I thought that was Rob's intention) - this doesn't break many products I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin. Like what exactly? With all due respect, the 1.6 branch should *not* break stuff that works find on 1.5. The specific goal for 1.6 was to be 1.5 plus GenericSetup so that it stays 1.5-compatible. This change has nothing to do with GenericSetup from all I can tell. Please don't just say OK, change it back if you want, but there may be traps elsewhere. I do not know what all needs to be changed. I'll be happy to do it, but I need to know what else is involved. yes, i believe the agreement was to try to keep 1.6 as close to 1.5 as possible, with the exception of GenericSetup. the types stuff is the greyest area, however, because the changes in the way TypeInfo objects are handled btn 1.5 and 2.0 has a considerable impact on the setup profiles and the import/export nodes. my original idea was to have the 1.6 types import adapter use the 2.0 style, containment-based profile format, but to generate 1.5 style TypeInfo objects. i haven't had time in recent weeks to keep up w/ all of the stuff that you've been doing, yuppie, but i do have a bit of concern that we're causing too much divergence btn 1.5 and 1.6 operationally. if we stray too far, then tres will stop forward-porting any 1.5 fixes that he might make... ;-). -r ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Hi Rob! Hi Jens! Rob Miller wrote: Jens Vagelpohl wrote: On 20 Dec 2005, at 19:53, yuppie wrote: The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way. I fixed the new machinery because - most code used already the new machinery (and I thought that was Rob's intention) - this doesn't break many products I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin. Like what exactly? With all due respect, the 1.6 branch should *not* break stuff that works find on 1.5. The specific goal for 1.6 was to be 1.5 plus GenericSetup so that it stays 1.5-compatible. This change has nothing to do with GenericSetup from all I can tell. Please don't just say OK, change it back if you want, but there may be traps elsewhere. I do not know what all needs to be changed. I'll be happy to do it, but I need to know what else is involved. Besides the import/export handlers Rob mentions below this affects all the TypesTool code that used 'typeClasses' (grep for it in 1.5) and the add forms for type infos. yes, i believe the agreement was to try to keep 1.6 as close to 1.5 as possible, with the exception of GenericSetup. the types stuff is the greyest area, however, because the changes in the way TypeInfo objects are handled btn 1.5 and 2.0 has a considerable impact on the setup profiles and the import/export nodes. my original idea was to have the 1.6 types import adapter use the 2.0 style, containment-based profile format, but to generate 1.5 style TypeInfo objects. i haven't had time in recent weeks to keep up w/ all of the stuff that you've been doing, yuppie, but i do have a bit of concern that we're causing too much divergence btn 1.5 and 1.6 operationally. if we stray too far, then tres will stop forward-porting any 1.5 fixes that he might make... ;-). I really don't care much about how this is resolved. But from Rob's checkins and the discussion following this mail http://mail.zope.org/pipermail/zope-cmf/2005-November/023399.html I had the impression that CMF 1.6 should provide backwards compatibility for Products written for Plone 2.1, not for Plone 2.1 itself. CMFDynamicViewFTI is an integral part of Plone 2.2 and I would be surprised if any other Plone product registers its own type info class. AFAICS the same applies to FlexibleTypeInformation and CPS. I don't think that my backports from the trunk widened that gap between 1.5 and 1.6. It existed from the beginning of the 1.6 branch. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 20 Dec 2005, at 21:56, yuppie wrote: yes, i believe the agreement was to try to keep 1.6 as close to 1.5 as possible, with the exception of GenericSetup. the types stuff is the greyest area, however, because the changes in the way TypeInfo objects are handled btn 1.5 and 2.0 has a considerable impact on the setup profiles and the import/export nodes. my original idea was to have the 1.6 types import adapter use the 2.0 style, containment-based profile format, but to generate 1.5 style TypeInfo objects. i haven't had time in recent weeks to keep up w/ all of the stuff that you've been doing, yuppie, but i do have a bit of concern that we're causing too much divergence btn 1.5 and 1.6 operationally. if we stray too far, then tres will stop forward-porting any 1.5 fixes that he might make... ;-). I really don't care much about how this is resolved. But from Rob's checkins and the discussion following this mail http://mail.zope.org/pipermail/zope-cmf/2005-November/023399.html I had the impression that CMF 1.6 should provide backwards compatibility for Products written for Plone 2.1, not for Plone 2.1 itself. CMFDynamicViewFTI is an integral part of Plone 2.2 and I would be surprised if any other Plone product registers its own type info class. AFAICS the same applies to FlexibleTypeInformation and CPS. I don't think that my backports from the trunk widened that gap between 1.5 and 1.6. It existed from the beginning of the 1.6 branch. I have a feeling that I am the first one who tried to run Plone 2.1 on CMF 1.6, which is why no one noticed before. I certainly would have spoken up if I had come across it as I have now. After reading the thread you mention, which isn't all that clear when it comes to outlining what the consequences of some of these code changes are, I'm confused. I think I can boil it down to one question: What is the use of the CMF 1.6 branch if it is not compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and possibly not even 2.2 since that's only a few months down the road? I don't quite understand the distinction between compatible with products written for Plone 2.1 but not with Plone 2.1, I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Hi! Jens Vagelpohl wrote: On 20 Dec 2005, at 21:56, yuppie wrote: I really don't care much about how this is resolved. But from Rob's checkins and the discussion following this mail http://mail.zope.org/pipermail/zope-cmf/2005-November/023399.html I had the impression that CMF 1.6 should provide backwards compatibility for Products written for Plone 2.1, not for Plone 2.1 itself. CMFDynamicViewFTI is an integral part of Plone 2.2 and I would be surprised if any other Plone product registers its own type info class. AFAICS the same applies to FlexibleTypeInformation and CPS. I don't think that my backports from the trunk widened that gap between 1.5 and 1.6. It existed from the beginning of the 1.6 branch. I have a feeling that I am the first one who tried to run Plone 2.1 on CMF 1.6, which is why no one noticed before. I certainly would have spoken up if I had come across it as I have now. It might be that the problem was hidden before I removed the typeClasses list. But the typeClasses list wasn't really used on the 1.6 branch. Only in manage_addTypeInformation, where the new way to register type info classes was ignored. After reading the thread you mention, which isn't all that clear when it comes to outlining what the consequences of some of these code changes are, I'm confused. I think I can boil it down to one question: What is the use of the CMF 1.6 branch if it is not compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and possibly not even 2.2 since that's only a few months down the road? I don't quite understand the distinction between compatible with products written for Plone 2.1 but not with Plone 2.1, I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. That might have changed over time, but the code never reflected that change. I'm fine with any decision as long as someone else does the necessary work. Cheers, Yuppie ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 20 Dec 2005, at 23:32, yuppie wrote: After reading the thread you mention, which isn't all that clear when it comes to outlining what the consequences of some of these code changes are, I'm confused. I think I can boil it down to one question: What is the use of the CMF 1.6 branch if it is not compatible to Plone 2.1/2.1.1 and 2.1.2 when it comes out, and possibly not even 2.2 since that's only a few months down the road? I don't quite understand the distinction between compatible with products written for Plone 2.1 but not with Plone 2.1, I can't see any sense in that route... it all comes back to one question: What is the goal for the 1.6 branch? What specific audience is it targeted at? I can see what it's apparently *not* targeted at: People who work with Plone 2.1 - including those that might be interested in taking up GenericSetup for their Plone product. I had thought that was our audience. AFAICT the original target audience were people that want to switch to Plone 2.2 and reuse Products written for 2.1. That might have changed over time, but the code never reflected that change. Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6-compatible then? jens ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
Unless someone fixes that CMFDynamicsomethingFTI thing (or the CMF 1.6 branch) people cannot even attempt to run Plone 2.1 or 2.2 against CMF 1.6. This is like a stalemate. Can you suggest how to add a new kind of factory information class similar to appending it to that typeClasses structure so Martin can fix the Plone code for whatever release they want to make CMF 1.6-compatible then? We can obviously fix this, so long as we maintain API compatability. A lot of products use CMFDynamicViewFTI, but only through the interfaces defined there and in CMFPlone/interfaces/browserdefault.py. *If* this is indeed a better solution, we'd need to know *how* to change CMFDynamicViewFTI to use the new machinery. That code is fairly small and simple, and someone who knows how an FTI works should hopefully not have much problem understanding how it works. If you can outline how to fix it, I'm sure we could get one applied and into a release timed to the switch to CMF 1.6. Martin -- (muted) ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
