That's a great piece of work you did, thanks!
I've been following package releases and have noticed some mistakes
mainly in changelog formatting:
> 3.5.0 (unreleased)
> * Added support to bootstrap on Jython.
> * Use zope.container instead of zope.app.container.
Well, it IS released :) Also it doesn't really "use" zope.container or
zope.app.container, there's just a comment in the .c file :)
> 3.4.2 (unreleased)
> 3.4.1 (2009-01-26)
Again, it IS released. Also some changelog entry is missing :)
Also, please, check the buildout.cfg of the zope.container, because it
still includes some local developer develop paths and recipes.
2009/1/31 Martijn Faassen <faas...@startifact.com>:
> Hi there,
> I've just made a lot of releases as the result of our dependency cleanup
> sprint. There are more releases to be made, but I think I've released
> the most important affected packages now. Christian Theune is going to
> follow up and release some more packages that we touched, probably tomorrow.
> I'm going to write up a document that describes how we analyzed
> dependencies and what approaches we took so that people who want to help
> have some idea of what to do.
> the most important affected packages are (as far as I can remember):
> zope.app.component ('class' ZCML directive moved into zope.security,
> site stuff extracted into zope.site)
> zope.app.security ('module' directive moved into zope.security, along
> with some helper functions)
> zope.app.container (most functionality moved into zope.container)
> zope.app.folder (base class moved into zope.container, Folder itself
> moved into zope.site as its main function was to mix in site management
> zope.traversing (depends on zope.location now instead of the other way
> zope.location (doesn't depend on zope.traversing anymore)
> zope.site (a new package extracted from zope.app.component and
> zope.container (a new package extracted from zope.app.container and
> Another thing we want to do is reduce the test dependencies of packages
> to almost nothing (or nothing at all). We think it'd be good if package
> only used what they depend on directly for testing purposes; testing
> dependencies in general should follow implementation dependencies. This
> might allow us to get rid of zope.app.testing at some point. Instead
> we'd like to see more (and more consistent!) 'testing' modules in
> packages that help with test setup.
> We have created a bunch of tools in the process of reducing
> dependencies: an extension to the test runner to track imports that
> could be modified to be from a better location (though 'grep' is very
> useful there too), z3c.recipe.compattest, and Christian Theune is
> working on a way to 'touch' the ZODB so that it will update any moved
> class to the new location.
> Note that we haven't finished going through the codebase changing
> imports from zope.app.folder to zope.site where possible - volunteers
> are welcome. This should further reduce dependencies in the entire graph
> as zope.site pulls in far less than zope.app.folder.
> If a bunch of us keep this up we'll that'll allow us to start retiring a
> lot of packages that are mostly unused, and have a smaller, easier set
> of Zope 3 packages to maintain and understand. Users of the Zope 3
> libraries (plain Zope 3, Grok, Zope 2, Repoze, and others) should all
> benefit from this.
> Zope-Dev maillist - Zope-Dev@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
WBR, Dan Korostelev
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -