Along with David Glick, I would like to volunteer for the Zope 4
release management role, where I would take responsibility for
producing the initial release of Zope 4 and David would then take over
for the maintenance releases.

In doing so, I thought it would be helpful to set out our
understanding of the mission of Zope 4. If accepted I'll work to
produce a first draft of a roadmap based on the outcome of the recent
sprints and discussions on this mailing list.


Zope 4 will be the first of several releases that seek to simplify our
software stack. Over the years Zope 2 grew through the adoption of new
technologies, notably Zope 3, but rarely removed older ways of doing
things. Below, 'Zope 4' refers to the series of releases including
Zope 5, 6, etc.

Over the series of releases, Zope 4 will progressively remove more and
more software as we transition to using software components shared
with other Python web frameworks.

It is as important to state what Zope 4 *is not* as what it should be:

* Zope 4 will not seek to be of interest to those developing new
applications. They should instead look to projects such as Pyramid
that build on the experience and technologies of Zope without regard
for the backwards compatibility concerns that will constrain Zope 4.

* Zope 4 will not seek to innovate in itself but encourage innovation
in software components shared with the wider Python web community.

* Zope 4 will not move so quickly that it becomes impossible to make
Plone, its main consumer, work with it.

* But neither will Zope 4 seek to retain backwards compatibility at
any cost. As the basis of Plone 4, Zope 2.13 will see maintenance
releases as long as Plone 4 is supported.

* Zope 4 will not have a release cycle independent of Plone. Zope 4
only exists as a transitional path for Zope 2 based applications and
experience has shown that Zope 2 releases not used in any Plone
release do not receive the same level of ongoing maintenance.

Development Process

We want to encourage all features to be developed on separate feature
branches so we can maintain a stable trunk. Before these feature
branches are merged they should be posted to the mailing list for

This process will  necessitate a lot of merging, so I want to propose
that we move to Git for development (something we found very helpful
at our recent San Francisco Zope 4 sprint.) I don't have any opinion
on where the canonical repository should be hosted - I know some
people have strong opinions that this should be on Zope Foundation
controlled hardware. If that's to be the case then we will need the maintainers to setup a shared git repository on that
machine. I think mirroring to github (and/or launchpad in future) will
be the simplest way to provide an anonymously accessible and web
browsable copy.

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

Reply via email to