[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martin Aspeli 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. I'm not the release manager, so it's not my decision, but I think the argument goes something like, Zope 2.9 hasn't lived very long, and .0 versions of Zope have a history of having subtle security and performance bugs; similarly, those who just upgraded to Zope 2.8 may not want to upgrade again just yet. 2.8 is the conservative choice, for those who want the most stable, out-of-the-box Plone. 2.9 will likely be the choice for those who want the latest and greatest features from add-on products. Let's put it this way: By the time Plone 2.5 is releases (if according to roadmap), Zope 2.8 is one month away from being *discontinued*. Conservative or not, I wouldn't bet on a release line that won't receive bugfixes the minute I start using it... We will have to get used to the fact that Zope 2 release lines live shorter. They live for one year, to be exact. I think conservativism shouldn't extend beyond the age of Zope releases, unless the Plone people want to continue to maintain and release older Zope 2 versions on their own time. 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
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Philipp von Weitershausen wrote: [..] 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). Well, I was tinkering a little bit with Plone 2.1 on Zope 2.9 (or the Plone-2.1 bundle to be precise) not too long ago and all in all it seemed to work. The only thing I noticed immediately was that the tests couldn't be run but I didn't investigate that because I was too busy with other things. Hopefully it was only me missing something ... Raphael Philipp ___ 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
Raphael Ritz wrote: Philipp von Weitershausen wrote: [..] 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). Well, I was tinkering a little bit with Plone 2.1 on Zope 2.9 (or the Plone-2.1 bundle to be precise) not too long ago and all in all it seemed to work. The only thing I noticed immediately was that the tests couldn't be run but I didn't investigate that because I was too busy with other things. Hopefully it was only me missing something ... Just after sending the above I read whit's post on plone-dev announcing http://svn.plone.org/svn/collective/plonents/bundles/testing/ I guess that's what I was missing. Raphael Raphael Philipp ___ 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] Re: RFC: backporting including python-package-product support to support Zope 2.8
On Wed, 18 Jan 2006 00:45:14 -0800, Philipp von Weitershausen [EMAIL PROTECTED] wrote: Let's put it this way: By the time Plone 2.5 is releases (if according to roadmap), Zope 2.8 is one month away from being *discontinued*. Conservative or not, I wouldn't bet on a release line that won't receive bugfixes the minute I start using it... Note that I'm not saying it *won't* ship with 2.9, just that we reserve the right to ship with 2.8, since the 2.9 status is still uncertain, and since neither the Zope or Plone teams have released anything on the actual date of the deadline so far. I think it's great that we have a somewhat reliable time-based release schedule - but all the kinks are not worked out yet. ;) -- _ Alexander Limi · Chief Architect · Plone Solutions · Norway Consulting · Training · Development · http://www.plonesolutions.com _ Plone Co-Founder · http://plone.org · Connecting Content Plone Foundation · http://plone.org/foundation · Protecting Plone ___ 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: RFC: backporting including python-package-product support to support Zope 2.8
Andrew Veitch wrote: Let's put it this way: By the time Plone 2.5 is releases (if according to roadmap), Zope 2.8 is one month away from being *discontinued*. Conservative or not, I wouldn't bet on a release line that won't receive bugfixes the minute I start using it... Just so I'm clear, I've just checked the Plone 2.5 roadmap and it says it is due in 8 May this year - is it really true that Zope 2.8 is going to stop getting bugfixes in June this year? Yes. This was suggested by the Zope 2 release manager, Andreas Jung, two months ago: http://mail.zope.org/pipermail/zope-dev/2005-October/025554.html. Of course, other people are still welcome to backport fixes to the 2.8 branch and make releases themselves, but I suspect neither Andreas nor the Zope 2 developers will have the bandwidth to maintain more than three concurrent branches (Zope 2.9, Zope 2.10 and the trunk at that time). I think for those of us deploying Zope on an enterprise scale it will be pretty hard to do upgrades this frequently. I think one year is a pretty big span. Today, for example, you would not start a project on Zope 2.8. You would do it with Zope 2.9 which is going to get bugfixes until the end of 2006. Philipp ___ 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
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Martijn Faassen wrote: Is Plone 2.5 still targeting Zope 2.8? Yes. Yes to which question? Yes to Is Plone 2.5 still targeting Zope 2.8. Perhaps these use cases aren't driven by Plone/CMF core and some other packages would like to use this in Zope 2.8? Can they be identified? The general use case is to stop having to put things in Products. When now writing Zope 2 software, a lot of code basically expects stuff to be in Products, Rocky's modifications make that go away and add a ZCML directive to let Zope 2 pick up packages from outside Products (so that they will still receive the same initialization features and an entry in the Control_Panel, etc.). I know what the modifications allow you to do. It's a fundamentally different way of developing and installing products. Therefore it's good to ask why we would want to expose such a fundamentally new feature for Zope 2.8. Do we really want to start explaining to people that My product is special, you need to install it like this, unlike what you're used to when what we're dealing with is not even the most recent stable release of Zope? To be clear: I realize that this effort is to make things *less* special for Zope on the long term, and I support it's overall it with some reservations, but we have to think about the tactical short term too. Fair enough. It seems to several people, though, that explaining to people how Python packages are installed and then how you hook up these packages into your instances is easier than explaining all the magic that revolves around Products to them. Because in the end you won't have to explain how to install Python packages at all because it's the same all the time... As somebody who's somewhat involved in Zope documentation, I am one of those above mentioned people. For how long do we intend to evolve new features for what is not the most recent stable release of Zope? I.e. we can make the argument that this should be in the hands of the people soon for just about any new feature in Five. Good point. 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? Given Plone hasn't adopted time-based releases yet, I'm not sure. AFAIK they want time-based releases, 6 months apart like Zope. Just yesterday I suggested they make them 3 months off to the Zope releases. That way they can keep on track with Zope releases and not lag behind all the time. The reason for doing so is simple: Products is bound to go away. It gives a lot of people a lot of pain. With a lot of Zope 3 technology entering many Zope 2 projects, it would be good to get a clean slate early on: put new stuff on Product-less packages. You can turn that around; for consistency of installation experience in Zope 2.8, it's important that people don't get a new way of installing products, confusing innocent individuals installing Zope software. For the cutting edge, Zope 2.9, that argument is slightly different. I want to identify the reasons why it is so important that this change happens with Zope 2.8. The main reason I can identify is Plone, correct? I let Rocky take this one. I don't really feel strongly about having this available in Zope 2.8. Philipp ___ 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
Martijn Faassen wrote: Okay, I read CMF 2.0 is targetting Zope 2.9 now, but Plone is, as of yet, still targeting CMF 1.6. Whether they really will I guess also depends on Plone's commitment to release this spring and suppress changing things around. 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 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 - 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
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Philipp von Weitershausen wrote: Fair enough. It seems to several people, though, that explaining to people how Python packages are installed and then how you hook up these packages into your instances is easier than explaining all the magic that revolves around Products to them. Because in the end you won't have to explain how to install Python packages at all because it's the same all the time... Indeed, its time for Zope developers to think less like zope developers and think more like python developers :) 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? Given Plone hasn't adopted time-based releases yet, I'm not sure. AFAIK they want time-based releases, 6 months apart like Zope. Just yesterday I suggested they make them 3 months off to the Zope releases. That way they can keep on track with Zope releases and not lag behind all the time. My understanding is that Plone 2.1 - 2.5 was meant to be the first time based release. But Alec Mitchel would have to answer that one, being the release manager. I do support sync'ing these plone 6 month release cycles with zope's releases (being 3 months off) and I think I heard a few plone people second the sentiment. You can turn that around; for consistency of installation experience in Zope 2.8, it's important that people don't get a new way of installing products, confusing innocent individuals installing Zope software. For the cutting edge, Zope 2.9, that argument is slightly different. Well, any non-familiar zope2 sys admin who's installed plugins has almost certainly had to install python code in site-packages as well. Telling them oh, you can just stick this on site-packages as well, or put it in INSTANCE_HOME/lib/python if you need different versions with different zope instances I think won't confuse innocent individuals. I want to identify the reasons why it is so important that this change happens with Zope 2.8. The main reason I can identify is Plone, correct? Single biggest reason is so that people developing products within the next 6-12 months can develop using this new style. Of course we can say that as a consultant we just require our clients to upgrade to Zope 2.9, but the reality is we all have plenty of clients who won't be able or willing to make the upgrade from Zope 2.8 to 2.9 especially with the leap of going from py2.3 to py2.4. This has the biggest bearing on Plone because even though Plone 2.5 will support zope 2.8 and 2.9 both (I actually tried to convince them to drop support for 2.8, but that didn't work out), the majority will use zope 2.8 -- based on experience with Plone 2.1 supporting Zope 2.7 and 2.8 where most Plone 2.1 installs still seem to use Zope 2.7. I'm not a great debater by any means so I'll finish this with one more reason as to why and make Zope 2.8 support this functionality -- because it will make my life a great deal easier :) - 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
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Philipp von Weitershausen wrote: Yes. In fact, if one exists, it's automatically put on your PYTHONPATH for that instance. I think we should make Zope 2.8+ instance skeleta grow a lib/python directory. This can hardly be considered a feature, so we should be able to sneak it into the next bugfix releases of 2.8 and 2.9. +1 I was discussing this with someone a while back asking why we shouldn't just add this directory to the standard instance structure. A lot of zope2 developers still don't realize that INSTANCE_HOME/lib/python can exist and will get used if it does exist. - 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
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
Philipp von Weitershausen wrote: The general use case is to stop having to put things in Products. When now writing Zope 2 software, a lot of code basically expects stuff to be in Products, Rocky's modifications make that go away and add a ZCML directive to let Zope 2 pick up packages from outside Products (so that they will still receive the same initialization features and an entry in the Control_Panel, etc.). Rocky how does your effort relate to Basket by the way? ISTR that Basket aims at answering a similar use case. 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: RFC: backporting including python-package-product support to support Zope 2.8
Florent Guillaume wrote: Rocky how does your effort relate to Basket by the way? ISTR that Basket aims at answering a similar use case. Basket is for distributing zope2 products in egg form. I've been working with Chris closely on it. In fact I added the support that allows people to write zope2 products without the toplevel Products namespace package with eggs for Basket. Its there where I discovered the more prominent area's that needed to be monkey patched and reused that knowledge when adding similar work to Five. Once everything lands in Zope 2.10, there will be no need for the monkies in Basket (or possibly even Basket itself) or this Five work. - 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
[Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
i'm -1 for expending extra effort to get this working on Zope 2.8. new features should arrive w/ new versions. Plone 2.5 will require CMF-1.6, which will work w/ both Z2.8 and Z2.9. those who want this feature can run Plone on Z2.9, no prob. i'd much rather see us focus our efforts on getting people migrated forward to Z2.9 than give them reason to stay on Z2.8 yet longer. it's bad enough that we have to support Z2.8 w/ Plone 2.5, let's not make it worse. -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
Re: [Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
On 1/15/06, Philipp von Weitershausen [EMAIL PROTECTED] wrote: 2) work on the latest version of CMFonFive supported on Zope 2.8 (CMFonFive 1.2 svn branch) and provide a monkey patch for CMF 1.5 there. Why do we need to support CMF 1.5? We probably don't, but: If we want to make the modification on CMFonFive, we either must support CMF 1.5, or make a fourth current CMFonFive version. CMFonFive 1.2.x is for CMF = 1.5.1 and Five = 1.2 (And therefore Zope 2.7 and 2.8) CMFonFive 1.3.x is for CMF = 1.5.2 and Five = 1.2 (And therefore Zope 2.7 and 2.8) CMFonFive 1.4.x is for CMF = 1.5.2 and Five = 1.3 (And therefore Zope 2.9) Now, to support Zope 2.8 and Zope 2.9 with these changes, we need to put it both in 1.3 and 1.4, and we must then support both CMF 1.5 and 1.6. If we only want to support CMF 1.6, we need a CMFonFive 1.5.x that is for CMF = 1.6.0. CMFonFive version dance confuses the heck out of me, we should try to keep things simple. Yes, I agree. So I think all of CMFonFive, including these changes, should be in CMF 1.6. That ends the dance. It was a mistake to move half of CMFonFive into CMF. We should have moved all of it in, and called that 1.6 instead of 1.5.2 (but that's too late now). Doing this however, means that CMF 1.6 will NOT support Zope 2.8. I don't find that to be a problem, the everything works with everything seems to be too much work. But others might not agree. -- 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
Re: [Zope-CMF] Re: RFC: backporting including python-package-product support to support Zope 2.8
On 15 Jan 2006, at 12:04, Philipp von Weitershausen wrote: Lennart Regebro wrote: CMFonFive version dance confuses the heck out of me, we should try to keep things simple. Yes, I agree. So I think all of CMFonFive, including these changes, should be in CMF 1.6. That ends the dance. It was a mistake to move half of CMFonFive into CMF. We should have moved all of it in, and called that 1.6 instead of 1.5.2 (but that's too late now). Doing this however, means that CMF 1.6 will NOT support Zope 2.8. I don't understand why that should be. It's also against everything that was decided when CMF 1.6 was started. Plone 2.5, for example, will use CMF 1.6 and wants Zope 2.8 compat. Philipp is right, we really cannot drop Zope 2.8-compatibility for CMF 1.6. If you simply drop any further CMF 1.5 work and only had CMFonFive that works with CMF 1.6 regardless of Zope 2.8/2.9, what would that leave you with in terms of CMFOnFive versions? 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: RFC: backporting including python-package-product support to support Zope 2.8
Jens Vagelpohl wrote: What I am reading out of this is that *you* yourself have a burning desire to continue supporting 1.5. I don't quite get it. My biggest reason for wanting to support CMF 1.5 is so that Plone developers don't have to wait *at least* another 4 months before they can build plone python-packages-as-products. (Plone 2.5 will be the first Plone version to use CMF 1.6 and isn't scheduled for final release until May 8) - 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
