Tres Seaver wrote: > - How many projects are there which are going to need a "Zope 3.5" > release (as opposed to updates to some of the packages traditionally > part of Zope3)? I would bet that this set is smaller than the first. > For instance, I know that Zope 2.12 *says* it will rely on 3.5, but I > don't know what that means, actually. Grok already maintains the > moral equivalent of its own KGS, right?
I added the Zope 2.12 depends on Zope 3.5 sentence. What it means at this stage is that Zope2 defines a KGS (in concept but not fleshed out in the way you use it) which directly reuses the Zope 3.5 KGS by virtue of copying it's generated versions.cfg. Just to make this very obvious, this is the versions-zope2.cfg we have: [buildout] extends = versions-zope3.cfg versions = versions [versions] Acquisition = 2.12.0a1 DateTime = 2.11.2 ExtensionClass = 2.11.1 Persistence = 2.11.1 tempstorage = 2.11.1 zLOG = 2.11.1 And that is all there is. While Zope2 probably uses only a third of the packages tracked in the 3.5 KGS, the information about known-good status of the packages it uses, is still very valuable. Technically you would only need to add the above six lines and the Zope2 package itself to the controlled-packages.cfg of zope.release and the KGS part of it would be good for both projects. As the proposed release cycles of both 3.5 and 2.12 are in sync at this point in time, we have actually two options from the point of Zope2: 1. Merge the KGS information into one. We do have the same kind of policies for handling backwards incompatible changes, which largely dictate if new versions of packages are appropriate for inclusion. The generated web presentation of both projects is different of course. 2. Split the Zope 3 KGS into two parts: the Zope Framework bits and the Zope 3 Application Server bits. The "Zope Framework" as defined as zope.* is far less than Zope2 requires itself. zope.app.testing, zope.app.component, zope.app.form, zope.app.publisher and friends are all used and incur a major buy into the Zope3 Application Server today. So Zope2 does have an interest in a maintained Zope3 KGS and release still. Otherwise we do have to do this work ourselves. If we are to see a refactored publisher and some continued refactoring of dependency graphs, the common set might be getting a lot smaller for a Zope 2.13 / 3.6 release. But this is vapor ware at the current stage. >From my Plone perspective I do have even more of an interest in the Zope 3.5 KGS. In the high-level applications I built, z3c.form, zope.intid but also z3c.unconfigure and many more packages are often used. Being able to rely on a KGS of such a wider set of libraries is valuable to me. This however does not mean, that individual packages should be tightly pressed into the needs of such consumers of them. The overhead of tracking incompatible changes, creating maintenance branches where required and releasing maintenance releases of those, can be the burden of a different group of people, than the ones that drive a package forward in its own merit. Hanno _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )