Martijn Faassen wrote: >>> Yes, but Zope 2 included *less* than Zope 3 in the most recent >>> release, and I'd like *all* packages that are in a Zope 3 release to >>> be available in a Zope 2 release. I.e. Five doesn't want packages >>> that aren't in a Zope 3 release, but not less either. >> >> I'm surprised that it included less. > > It was a bug, and I think some of it already got resolved (Philipp would > know more), but it wasn't noticed until fairly late, as during > development such dependencies are development.
It included less due to an oversight on my side. I forgot to make the Zope 2 release depend on certain new zope.app packages that zope.app didn't already depend on. They were not included in Zope 2.9b1, but 2.9b2 quickly fixed that. It was my mistake. I don't think anything would've made it easier catching that mistake other than reports from the people. Also, it's a mute point now (please let's bury it!) as b2 already fixed it. While I got this email open, I'd like to quickly add my EUR0.02 as a summary of this thread: * Breaking Zope (3 that is) into subprojects is extremely useful. zope.testing was a good example, the next things should be zope.interface+zope.schema and zope.pagetemplate+zope.tales+zope.tal etc because there are actually standalone releases of these things or at least people using these things separately from Zope. * Moving things that aren't immanent to the Zope 3 application server out of zope.app is also a good thing. I suspect this is mostly a mechanical change (dropping the 'app' in the import name). Ideally this should indeed leave us with a zope.app that is so Zope3-specific that it isn't of any use for Zope 2. * We should indeed avoid having to include certain Zope 3 things into Zope 2 that don't make any sense in Zope 2. The whole zope.app.twisted machinery is an example. Currently we're not running zope.app tests in Zope 2 because we would have to stitch in twisted into Zope 2 svn! * Zope 2 should continue to use and provide as much Zope 3 functionality as Zope 3 does. This "policy" brought us zope.formlib to Zope 2.9 which is already being enjoyed by some Five developers! * We should get rid of vendor imports such as pytz, docutils and those testbrowser dependencies. Eggs will make this very trivial. We won't even be concerned about development mode or not because we're not modifying them anyways. I think the decision for time-based releases is a success, mostly because I already know when a new Zope release is to expected and roughly what features it'll bring. As someone who puts a lot of effort in Zope 3 documentation I find this extremely valuable as a planning asset. As for the December release itself, I'm not too impressed. On the Five/Zope 2 side of things it was more than people bargained for, namely the port of Five to Zope 3.2 and the packaging of Zope 2 with zpkg. It might be due to the fact that this was our first time-based release and people were just used to releases being postponed when they didn't find the time to commit to a schedule. Obviously this we can't continue like this in the future. If we move the release up to May (I'm +1) then feature freeze is in April. That effectively leaves us not much more than two months worth of time for work on Zope 3.3/2.10. What I want to say with this is that the right time to work on Zope 3.3/2.10 is *now*, not some time in the summer. Philipp _______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com