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 packages that
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 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 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
machinery is an example. Currently we're not running 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.

Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to