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:

extends = versions-zope3.cfg
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.,,, 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.


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

Reply via email to