[Zope-CMF] Re: future of getToolByName
whit wrote: I remember some discussion of this in the past. Transitionally, it would be helpful to be able to register local utilities to a tool name, and then have getToolByName spit out a deprecation warning and return an appropriate object. Why a deprecation warning and not just do it? IIRC the whole point of 'getToolByName' was from the very onset (years ago) to be forward compatible in terms of Zope 3. Relying on Z2's implicit acquisition, it would so far always be possible to just write tool = [context|self].tool-id and it would just work. Recommending to people to write from Products.CMFCore.utils import getToolByName tool = getToolByName([context|self], tool-id) was justified by the perspective that Zope 3 doesn't support implicit acquisition any longer *and* that the way how tools (now utilities) might get looked up in context may change. It was the promise that 'getToolByName' would always just do the right thing (TM) so that add-on developers would not have to worry. So why deprecating that now? Am I missing something? Raphael thoughts? comments? does this exist somewhere already? -w ___ 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 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] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open jens - Discussion replies removal, [Accepted] http://www.zope.org/Collectors/CMF/391 - 'CMF Default Workflow [Revision 2]' Extension broken, [Accepted] http://www.zope.org/Collectors/CMF/399 mhammond - Windows DevelopmentMode penalty in CMFCore.DirectoryView, [Accepted] http://www.zope.org/Collectors/CMF/366 regebro - fiveactionstool broken (Zope 2.9/3.2), [Accepted] http://www.zope.org/Collectors/CMF/392 Pending / Deferred Issues - Wrong cache association for FSObject, [Pending] http://www.zope.org/Collectors/CMF/255 - CMFSetup: Windows exports contain CR/LF, LF and even CR newlines, [Pending] http://www.zope.org/Collectors/CMF/266 - FSPropertiesObject.py cannot handle multiline input for lines, text attributes, [Deferred] http://www.zope.org/Collectors/CMF/271 - Can't invalidate skin items in a RAMCacheManager, [Pending] http://www.zope.org/Collectors/CMF/343 - CMFSetup: Workflow Tool export fails with workflows which have scripts, [Pending] http://www.zope.org/Collectors/CMF/373 - CMFCore.Skinnable.SkinnableObjectManager can merge skin data, [Pending] http://www.zope.org/Collectors/CMF/375 - Proxy Roles does't work for a Script using portal_catalog.searchResults, [Pending] http://www.zope.org/Collectors/CMF/380 - WorkflowAction deprecated warning should not printed for WorkflowMethod, [Pending] http://www.zope.org/Collectors/CMF/388 - workflow notify success should be after reindex, [Pending] http://www.zope.org/Collectors/CMF/389 - came_from and VIRTUAL_URL problem, [Pending] http://www.zope.org/Collectors/CMF/393 - DCWorkflow - Transition Guards - Documentation Bug, [Pending] http://www.zope.org/Collectors/CMF/394 - A workflow without managed permission can't be exported, [Pending] http://www.zope.org/Collectors/CMF/397 - Implicitly acquiring allow_discussion in isDiscussionAllowedFor, [Pending] http://www.zope.org/Collectors/CMF/398 Pending / Deferred Features - Favorite.py: queries and anchors in remote_url, [Pending] http://www.zope.org/Collectors/CMF/26 - DefaultDublinCore should have Creator property, [Pending] http://www.zope.org/Collectors/CMF/61 - path criteria on Topic should honor VHM, [Pending] http://www.zope.org/Collectors/CMF/111 - Document.py: universal newlines, [Pending] http://www.zope.org/Collectors/CMF/174 - Add condition for transition's action like other action, [Pending] http://www.zope.org/Collectors/CMF/207 - Major action enhancement, [Pending] http://www.zope.org/Collectors/CMF/232 - portal_type is undefined in initialization code, [Pending] http://www.zope.org/Collectors/CMF/248 - CMFTopic Does Not Cache, [Deferred] http://www.zope.org/Collectors/CMF/295 - Wishlist: a flag that tags the selected action., [Pending] http://www.zope.org/Collectors/CMF/301 - CMFDefault should make use of allowCreate(), [Pending] http://www.zope.org/Collectors/CMF/340 - Nested Skins, [Deferred] http://www.zope.org/Collectors/CMF/377 - CatalogVariableProvider code + tests, [Pending] http://www.zope.org/Collectors/CMF/378 - manage_doCustomize() : minor additions, [Pending] http://www.zope.org/Collectors/CMF/382 ___ 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: GenericSetup list property purge
Hi Florent! Florent Guillaume wrote: Florent Guillaume wrote: I recently introduced the fact that in extension profiles list properties aren't purged by default. But really this introduces problems, as if you simply import an extension profile twice you'll get all you lists doubled. So I think I'll use the opposite semantic, closer to what was the case before: purge by default for lists even in extension profiles, except if purge=False is present on the property. I checked this in. But actually this revealed what I think is slightly unclear behaviour in the case of loading extension profiles: the extension profile can happily modify objects without them being purged, but I believe that as soon as it has to create a new object, the import context should be switched to _should_purge=True for that object and the recursion inside it. What do you think? I don't like that idea: - Applying the settings to a new object should always have the same result as applying them to a purged object. If everything is implemented that way changing the purge mode to True doesn't make any difference in deeper levels. - You would need a way to mark those parts of the extension profile that should always create new objects (or purge them if they already exist). We already have purge=True for that. - I can't see how this would resolve your issue for purge=False. The handlers for other sequences (like skin paths and object managers) just add new sequence items if the item doesn't exist already. Wouldn't that also work for list properties? 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: Move GenericSetup out of CMF
Hi Jens! Jens Vagelpohl wrote: On 16 Jan 2006, at 18:28, Jens Vagelpohl wrote: On 15 Jan 2006, at 18:38, Jens Vagelpohl wrote: Before cutting the CMF 2.0 alpha GenericSetup should move out of the CMF repository. I'm volunteering to do that. Is there anything or anyone I need to wait on before doing so? Everyone: I'll be working on this tonight. Please get all checkins into GenericSetup done by 7:30 PM CST. Work finished, please check out GenericSetup from here now: svn+ssh://svn.zope.org/repos/main/GenericSetup/trunk The original proposal also proposed to include it in the CMF via a svn:external link, see http://palladion.com/home/tseaver/obzervationz/2006/cmf_2_0_update_20060111 Was that part skipped on purpose or by mistake? 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
Re: [Zope-CMF] Move GenericSetup out of CMF
On 17 Jan 2006, at 10:44, yuppie wrote: Work finished, please check out GenericSetup from here now: svn+ssh://svn.zope.org/repos/main/GenericSetup/trunk The original proposal also proposed to include it in the CMF via a svn:external link, see http://palladion.com/home/tseaver/obzervationz/2006/ cmf_2_0_update_20060111 Was that part skipped on purpose or by mistake? Ah, good catch. That sentence is in the paragraph below the actual blurb about the GenericSetup split-off. Obviously this is a 5 second thing to do, but it also will require constant maintenance to make sure the external is pointing to the right tag/branch/whatever. What do people think, do we want a svn:external or do we want to just mention it as a requirement in the docs (such as README, INSTALL, DEPENDENCIES)? 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: [z3-five] Re: RFC: backporting including python-package-product support to support Zope 2.8
I agree that Five development should happen in Five 1.4. This version would then be the basis for Five in Zope 2.10. Increasing Zope 3 compatibility there is good and high priority. Doing so in Five 1.2 is quite low priroty, since that runs on an old version of Zope 3, on which new development seems...not a very high priority. ___ 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: GenericSetup list property purge
On 17 Jan 2006, at 10:28, yuppie wrote: Florent Guillaume wrote: Florent Guillaume wrote: I recently introduced the fact that in extension profiles list properties aren't purged by default. But really this introduces problems, as if you simply import an extension profile twice you'll get all you lists doubled. So I think I'll use the opposite semantic, closer to what was the case before: purge by default for lists even in extension profiles, except if purge=False is present on the property. I checked this in. But actually this revealed what I think is slightly unclear behaviour in the case of loading extension profiles: the extension profile can happily modify objects without them being purged, but I believe that as soon as it has to create a new object, the import context should be switched to _should_purge=True for that object and the recursion inside it. What do you think? I don't like that idea: - Applying the settings to a new object should always have the same result as applying them to a purged object. If everything is implemented that way changing the purge mode to True doesn't make any difference in deeper levels. - You would need a way to mark those parts of the extension profile that should always create new objects (or purge them if they already exist). We already have purge=True for that. - I can't see how this would resolve your issue for purge=False. The handlers for other sequences (like skin paths and object managers) just add new sequence items if the item doesn't exist already. Wouldn't that also work for list properties? Yes but other sequences have an implicit semantics which is that elements cannot appear twice. Whereas here for properties that are lists we don't know the underlying semantics. It could be desired or not to have an element present twice. Not in my use case admittedly, but you never know. Up to know I just added elements to the list, without removing identical ones already present. What I can do is, for now, make purge=False have the exact semantics than for skins or objects (remove the old element first if it exists), but we know that at some point we may have to extend that semantic to provide things like append=True or append=always and append=once... We can probably avoid deciding that now. Florent -- Florent Guillaume, Nuxeo (Paris, France) 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: future of getToolByName
On 1/17/06, Raphael Ritz [EMAIL PROTECTED] wrote: It was the promise that 'getToolByName' would always just do the right thing (TM) so that add-on developers would not have to worry. So why deprecating that now? Because that promise has been completely revoked, since add-ons developed for old versions of CMF will not work on Zope 3 anyway. ;-) On 1/17/06, Rocky Burt [EMAIL PROTECTED] wrote: Hmm... I'm not sure this is useful unless we map standard utilities to the equivalently functioning tool (which I don't think is a good idea). Right, any tool that now exists must directly map unto a local utility, and that local utility must also have the same API. If we in CMF 2.0 feel that most tools should be made into utilities, we could register the utilities with a name, and use the old tool name. getToolByName could then both try local acquicistion, and do a query for a generic interface (ICMFTool?) with the name. The other option is to keep the tools, but also register them as utilities. That would probably need some changes in the utility registration, though, from the primitive implementation that is in 1.3. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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: Move GenericSetup out of CMF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: On 17 Jan 2006, at 10:44, yuppie wrote: Work finished, please check out GenericSetup from here now: svn+ssh://svn.zope.org/repos/main/GenericSetup/trunk The original proposal also proposed to include it in the CMF via a svn:external link, see http://palladion.com/home/tseaver/obzervationz/2006/ cmf_2_0_update_20060111 Was that part skipped on purpose or by mistake? Ah, good catch. That sentence is in the paragraph below the actual blurb about the GenericSetup split-off. Obviously this is a 5 second thing to do, but it also will require constant maintenance to make sure the external is pointing to the right tag/branch/whatever. What do people think, do we want a svn:external or do we want to just mention it as a requirement in the docs (such as README, INSTALL, DEPENDENCIES)? I don't think the burden of maintaining 'svn:external' is worse than the burden of maintaining the correct version ID in DEPENDENCIES.txt. I *want* to distribute GenericSetup with the CMF tarball, in fact, which makes 'svn:external' seem the Right Thing (TM). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDzQ+e+gerLs4ltQ4RAhYBAJ9c7inuwcwTRLtwtxeC+TLvLocdGACeOL99 W9UxZRaXvn/hx9rZT4CKWu0= =fWRt -END PGP SIGNATURE- ___ 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: Move GenericSetup out of CMF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: On 17 Jan 2006, at 15:39, Tres Seaver wrote: What do people think, do we want a svn:external or do we want to just mention it as a requirement in the docs (such as README, INSTALL, DEPENDENCIES)? I don't think the burden of maintaining 'svn:external' is worse than the burden of maintaining the correct version ID in DEPENDENCIES.txt. I *want* to distribute GenericSetup with the CMF tarball, in fact, which makes 'svn:external' seem the Right Thing (TM). OK, I'll stitch that in tonight and change the docs back. I will point it at the trunk for right now since thats all there is at this point. I will look at making a 1.1 release for it to correspond with the CMF 2.0 beta. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDzRew+gerLs4ltQ4RAtL0AKCCa+4FQ9i9tG0IkQBL19i48+CqoQCgrITp hm1y+s5RZNx/dUGTMrMzP2k= =3ugd -END PGP SIGNATURE- ___ 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: Move GenericSetup out of CMF
On 17 Jan 2006, at 16:13, Tres Seaver wrote: I don't think the burden of maintaining 'svn:external' is worse than the burden of maintaining the correct version ID in DEPENDENCIES.txt. I *want* to distribute GenericSetup with the CMF tarball, in fact, which makes 'svn:external' seem the Right Thing (TM). OK, I'll stitch that in tonight and change the docs back. I will point it at the trunk for right now since thats all there is at this point. I will look at making a 1.1 release for it to correspond with the CMF 2.0 beta. Wouldn't it be better to make a 1.1 release to correspond with the 2.0 final? Or are you following the same betas that CMF will have for 2.0? 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: future of getToolByName
howdy lennart! Right, any tool that now exists must directly map unto a local utility, and that local utility must also have the same API. If we in CMF 2.0 feel that most tools should be made into utilities, we could register the utilities with a name, and use the old tool name. getToolByName could then both try local acquicistion, and do a query for a generic interface (ICMFTool?) with the name. this is sort of what I'm thinking. I'd also like to backport whatever we decide on to cmf1.6. The other option is to keep the tools, but also register them as utilities. That would probably need some changes in the utility registration, though, from the primitive implementation that is in 1.3. I'm less for this. one of the big advantages that plone is looking forward to is cleaning out the tool litter out of the portal root. I think forward porting old tools to utilities is acceptable if we don't force the change on developers. -w ___ 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] CMF 2.0 alpha this coming weekend
Hi all, I will cut the CMF 2.0 alpha this coming Sunday, no matter what. I'll do as much as I can myself as far as cleanup goes beforehand, but in order to get it out I'm no longer waiting for others' tasks. The alpha is *not* the branching point for a 2.0 branch, that happens when the first beta is cut. Please view this alpha as a reminder that we need to get a move on to get the trunk ready for a beta and thus feature-completion. I would hope (feedback welcome) that we could have a beta two weeks from this coming Sunday. Once the alpha is out I will start doing some simple documentation and roadmap a la What's new in CMF 2.0?. 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: Move GenericSetup out of CMF
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jens Vagelpohl wrote: On 17 Jan 2006, at 16:13, Tres Seaver wrote: I don't think the burden of maintaining 'svn:external' is worse than the burden of maintaining the correct version ID in DEPENDENCIES.txt. I *want* to distribute GenericSetup with the CMF tarball, in fact, which makes 'svn:external' seem the Right Thing (TM). OK, I'll stitch that in tonight and change the docs back. I will point it at the trunk for right now since thats all there is at this point. I will look at making a 1.1 release for it to correspond with the CMF 2.0 beta. Wouldn't it be better to make a 1.1 release to correspond with the 2.0 final? Or are you following the same betas that CMF will have for 2.0? Certainly for the final; I think GS will be releasable in time to have the CMF 2.0 beta's svn:external point to a tag, rather than the trunk + revision ID. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDzRvm+gerLs4ltQ4RAiM7AKC7cFJ9dzBNXCsl2MLp2spXstQFNgCgqdbR 3qK4ro6vQJtyymxHZFRloVk= =Vd/E -END PGP SIGNATURE- ___ 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: Move GenericSetup out of CMF
On 17 Jan 2006, at 15:39, Tres Seaver wrote: What do people think, do we want a svn:external or do we want to just mention it as a requirement in the docs (such as README, INSTALL, DEPENDENCIES)? I don't think the burden of maintaining 'svn:external' is worse than the burden of maintaining the correct version ID in DEPENDENCIES.txt. I *want* to distribute GenericSetup with the CMF tarball, in fact, which makes 'svn:external' seem the Right Thing (TM). OK, I'll stitch that in tonight and change the docs back. I will point it at the trunk for right now since thats all there is at this point. 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: Move GenericSetup out of CMF
Jens Vagelpohl wrote: OK, all done now. jens Hmm... I think you forgot to do the svn:externals for CMF 1.6 branch too? (was GenericSetup removed from there as well?) - Rocky -- 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: Move GenericSetup out of CMF
On 17 Jan 2006, at 20:47, Rocky Burt wrote: Jens Vagelpohl wrote: OK, all done now. jens Hmm... I think you forgot to do the svn:externals for CMF 1.6 branch too? (was GenericSetup removed from there as well?) No I did not. snip Log message for revision 41349: - stitching GenericSetup back in as a svn:external and update docs. Changed: _U CMF/branches/1.6/ U CMF/branches/1.6/CHANGES.txt A CMF/branches/1.6/EXTERNALS.txt U CMF/branches/1.6/INSTALL.txt U CMF/branches/1.6/INSTALL_SVN.txt snip 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] DeprecationWarnings for container events
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent, I'd like to get the CMF-trunk clean of Deprecation warnings, at least when running unit tests or starting up Zope, and those emitted by OFS.subscribers are the remaining ones I know about. How do you mean for objects to handle the case where *they* need to respond to container events. E.g., the CookieCrumbler needs to register / unregister itself as a traversal hook on its container; there is no external subscriber which should be responsible for that (unlike, say, the catalog or the workflow tool). WRT content, do you have code in hand which makes the catalog and workflow tools subscribers, so that we could rip out the 'manage_afterAdd' and 'manage_beforeDelete' from the content base class? Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDzVyb+gerLs4ltQ4RAqS4AKCIx2qIMqq242fusv8TpRYUvYyKlgCeKl54 3GrzNHvSayGrjLuBo85asHM= =i0rH -END PGP SIGNATURE- ___ 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: Re: RFC: backporting including python-package-product support to support Zope 2.8
On Mon, 16 Jan 2006 11:41:23 -, Martijn Faassen [EMAIL PROTECTED] wrote: How urgent is it that all of this works with Zope 2.8? I guess it's urgent if you want to sell it to the Plone community, which will only switch to Zope 2.9 or beyond by next year or so, I expect. How much more often is this kind of thing therefore going to happen? Zope 2.7 is now the officially supported shipped-with version of Plone 2.1, but we also support Zope 2.8. Many products, including mine, require Zope 2.8 (or usually only Zope 2.7 + Five). I believe the plan is to require Zope 2.8 and support Zope 2.8 for Plone 2.5 in the same way. I don't really see the problem with this, because Plone 2.5 won't use any of this stuff internally anyway - it's only for add-on products. I have no problem requiring the users of my products to upgrade to Zope 2.9. I would assume that those users who want to use these new features either don't care, or are sophisticated enough to find ways around any particular backwards/forwards compatability problems they may have. So my vote is, leave Zope 2.8 alone if it's too much hazzle, and put the effort into making sure Plone 2.5 runs flawlessly on Zope 2.9. 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: RFC: backporting including python-package-product support to support Zope 2.8
On Mon, 16 Jan 2006 15:50:44 -, whit [EMAIL PROTECTED] wrote: In actuality, the number of products that anyone depends on will not be using this in 2.8, but making it available to 2.8 will give people an opportunity to use this and familiarize themselves. for example, Plone will be on 2.8 for at least another 6 or more months. And some Plone installations, indefinitely longer.. I think people will be on Zope 2.8 until the one product they really want/need requires Zope 2.9 and then they upgrade. I write everyhing for 2.8 now, even though Plone 2.1 also supports Zope 2.7. It's not that hard to upgrade Zope (at least not if you managed to install it in the first place). And people won't start using and familiarising themselves with these tools because it's available in their Zope version. They'll start because they read some documentation and saw some good examples and thought, hey, I ought to be working like that. And if that documentation says, step 1 - upgrade to Zope 2.9, so what? 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: RFC: backporting including python-package-product support to support Zope 2.8
Martin Aspeli wrote: The broader point is we wouldn't really need it yet - we don't have any code that actually uses these new features, and plenty of code that may be broken by changes in CMF 2. All in good time - of course, if you want to help work on CMF 2.0 compatability for the 2.5 branch when it starts stabilising, all the more chance we can get it into Plone 3.0 :) i have every intent of pushing for Plone 3.0 to require CMF 2.X (for some reasonable value of X). in fact, my first efforts towards GenericSetup and Plone integration were based on running Plone against the CMF trunk. it was then (correctly, IMO) decided that CMF 2.0 would cause too much breakage to 3rd party Plone products, when the last major release of Plone had already required most products to be rewritten. one of the biggest motivators for creating CMF 1.6 and using it for the basis of Plone 2.5 was so that it would be easier to do parallel Plone development against CMF 2.0 without having to maintain separately two entirely different site creation infrastructures. -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: RFC: backporting including python-package-product support to support Zope 2.8
On Mon, 16 Jan 2006 14:37:41 -, Rocky Burt [EMAIL PROTECTED] wrote: I think there are two reasons Plone 2.5 is targetting CMF 1.6 (instead of just going to CMF 2.0) 1) the risk that CMF 2.0 wouldn't be ready when plone -- and I'm pretty sure the 6 month release rule has already been adopted for Plone with Plone 2.1 - 2.5 trying to be the first 6 month interval This is correct, and PLIP freeze date has already passed, so now new crazy things at this point. 2) CMF 2.0 changes too many things -- because of the plethora of existing plone products out there and the pains that people are going through porting them from Plone 2.0 - 2.1, the Plone community is striving to not do the same thing going from Plone 2.1 - 2.5 Even more true, and it's in pre-alpha 1. Yipes. :) The broader point is we wouldn't really need it yet - we don't have any code that actually uses these new features, and plenty of code that may be broken by changes in CMF 2. All in good time - of course, if you want to help work on CMF 2.0 compatability for the 2.5 branch when it starts stabilising, all the more chance we can get it into Plone 3.0 :) 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: RFC: backporting including python-package-product support to support Zope 2.8
Alexander Limi wrote: From what you're saying I deduct that Plone 2.1 favours Zope 2.7 over 2.8. Below you are suggesting that Plone 2.5 should do the same with Zope 2.8 (favouring it over 2.9). I don't understand why that should be. If one version has to be favoured at all, it should be the most recent one. That way it's made clear that the lower version (2.7, 2.8) is only still supported as a courtesy for those who don't want to upgrade right now. All other Plone developers and users should preferrably use the highest stable of Zope, otherwise Plone will continue to lag behind at least one Zope major release. Well, this depends on what release ships when. We made a decision not to ship Zope 2.8.0 as the standard in the installers when shipping Plone 2.1 - and that turned out to be a good choice, based on the number of problems it had. I can guarantee you that Plone 2.5 will not ship with a Zope 2.9.0. A Zope 2.9.(1|2|3) might be possible, but there's no way we are shipping a .0 release of Zope with Plone. Once burnt, twice shy. :) There are indeed some issues to be sorted out with Zope 2.9 (Windows installer, premature zLOG deprecation, etc.), all of which aren't too big anymore, though. I think we can and should have a 2.9.1 bugfix release relatively soon. By looking at http://plone.org/products/plone/roadmap, Plone 2.5 will be out by 2006/05/08. By then Zope 2.9 can be considered stable and shippable I would say. Heck, by that time we'll already have a 2.10beta if I'm not mistaken. That and make the upgrade from Zope 2.7/2.8 to 2.9 flawless as well as make 2.9 the *recommended* version for Plone 2.5. Then I don't think it should be much of a problem for Rocky to not have this available in 2.8, except perhaps if he wants to get started right now, with Plone 2.1 (though that might still run under Zope 2.9 and CMF 1.6, I hope). What we ship in installers is one thing, what we personally use and recommend is another. The installers will always be more conservative when choosing versions. I can understand that reasoning. Fortunately, time-based releases will let us schedule these things in advance. E.g. by looking at the Plone 3.0 roadmap we can say that it will be relatively safe for it to depend and ship with Zope 2.10, coming out more than 3 months after the Zope 2.10 final release. Philipp This message was sent using IMP, the Internet Messaging Program. ___ 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
