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
Re: [Zope-CMF] Re: CMF 1.6 change broke Plone compatibility
On 22 Dec 2005, at 03:10, Rob Miller wrote: Jens Vagelpohl wrote: 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. the original motivation behind my request for a CMF 1.6 release was so that it could be used as a basis for the next major Plone release, what is now being called Plone 2.5. this is because Plone would like to switch to using GenericSetup for its site instantiation and configuration, but using CMF 2.0 for our next release would cause too much breakage of Plone add-on products. CMF 1.6 makes it easier for Plone to not fall (again!) terribly behind CMF's development cycle. Just to put this into perspective, this is not some life-and-death issue for me at this point, more a clarification issue. It wasn't clear to me how limited the target audience for CMF 1.6 really will be. 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. By the way, my technical problem of satisfying dependencies on GenericSetup introduced by us switching to PAS without breaking a production Plone 2.1 site have been solved by simply using GenericSetup from the 1.6 branch and keeping everything else at CMF 1.5.4. 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
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
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
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=40364&r1=40360&r2=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
