I was just thinking about the future of the "ZTK", and in the past I have argued for not attempting to version the entire set of packages that currently comprises Zope 3 over time as "ZTK releases". Instead, I have argued for promoting packages that have some life of their own (independent of the rest of the pile) into subprojects that have their own release cycles. Then outside projects such as Plone and Grok could depend on independent versions of such packages, giving them slightly more flexibility than requiring a "version of the ZTK". Given that this suggestion has been met with skepticism, let me try another tact. Instead of thinking about it this way, could we think about it as *deflating* the current set of zope.* packages that do not currently have a meaningful life of their own into a single setuptools distribution named "ZTK". This package would include most everything in zope.app*, plus things like zope.server, zope.publisher, and other things that just aren't useful outside of Zope-the-appserver, or which currently just depend on "too much". This "ZTK" distribution would *not* include packages that already have a life of their own outside Zope such as zope.interface, zope.component, zope.configuration, zope.proxy, ZODB, etc. These packages would continue to have their own release cycles. Over time, we'd tease out the dependencies of packages that live in the ZTK distribution, making them useful outside without any dependency on the ZTK. The names of these packages could be arbitrary (they wouldn't need to retain their old "zope.*" names). Some backwards dependency shims would be added to the ZTK to prevent old imports from breaking, and the ZTK distribution would then just have a dependency on the thing that got broken out. I'm thinking that this would simplify things greatly for people who want to be consumers of "truly independent" Zope packages. There'd be exactly N of them available for download (where N is much less than 100, more like 20), plus the ZTK, which would have the rest of the pile in it over time. If someone wanted to use a forked version of a package that lived in the ZTK distribution, they'd either do so by teasing out the dependencies and making it "truly independent" or they'd just reroll a custom version of the entire ZTK distribution. Does this make any sense? - C - C