[Zope-dev] Zope 4 release management

[Hanno Schlichting]

On Mon, Feb 6, 2012 at 4:41 PM, Martijn Faassen <faassen at startifact.com> wrote:
>>> I would actually argue that "Zope4" have no real release cycle at all:
>>> instead, the individual pieces which make up Zope should have their own
>>> cycles, with perhaps a ZTK-like tracking set that Plone and others use as
>>> platform targets.

not sure whom I'm quoting here, but: Zope 2 is special in that it
still has one big library named Zope2 at its center. It's not just a
collection of libraries. And a lot of the bigger changes being
proposed need coordinated changes to multiple libraries. Like the
__parent__ work or likely any non-trivial change to publication. You
can likely evolve DateTime, Record, Missing or DocumentTermplate on
their own - but that's not terribly exciting.

> I agree; actually "ZTK-like tracking set" is really already talking about
> doing releases, just like the ZTK has releases. And just like ZTK releases
> do, this needs some release management effort.
>
> Now I would advocate that Zope 4 releases mimic the ZTK in the way things
> are managed.

Just to clarify: Do you mean in terms of its release team? So instead
of having one release manager constituting a team? A team representing
the different consumer groups of Zope? Something like Plone, pure-CMF,
non-CMF?

In terms of its scope Zope 4 is meant to be a feature release, which
needs coordination and decisions on what to include. That makes it a
bit different from the ZTK, where the release team explicitly stays
out of setting development direction and avoids influencing what
happens in each library.

So I'm not sure the ZTK release team model is directly applicable to
Zope 4. The ZTK works fairly well for a mostly stable set of
libraries, where not much happens and at most quarterly bug fix
releases are needed.

Hanno