On May 3, 2007, at 4:56 AM, Christian Theune wrote:


I'm in front of the same wall that Fred was going up. ;)

I talked to Zagy about the problems we're facing with the current egg
releases of projects that live in Zope3/src/zope/ and
Zope3/src/zope/app/ and wrote this up a bit:


When working with eggs, we need to carefully use version numbers for the
releases and be able to do continuous releases.

By continuous releases, do you mean releases with version numbers that look like: 1.1dev-r1234? If so, I'm not convinced we'll need this at steady state for most projects. For most packages, regular releases, possibly augmented by the occasional alpha or beta release should be enough, IMO.

This is currently a bit

- Coding in the tree doesn't force you to get the individual
dependencies right, especially when dependencies evolve over time and
require constraints based on the version number.

- Releasing and tagging doesn't go together very well in this schema,
although continuous releases shouldn't require tags anyway. The normal
continuous releases from setuptools get somewhat awkward because we have
the indirection of the external.

The current schema of making projects with externals pointing into the Zope tree was always meant to be a temporary measure.

I was trying to think about the constraints of handling the large tree
when moving the code of all projects into satellite projects. IIRC the
requirement is that all projects that we move out now will get a common
version number.

I don't think that is a requirement. It is a likely consequence of the fact that they will likely already have been released with a common version number. Because version numbers should be increasing, they will tend to stay in sync for a while.


Here is what we found would be workable and would like to do later today
before doing the beta release. I call this approach "synchronized
satellites" picking up on the terminology Fred came up with. ;)

- Move the code of the remaining projects into the satellite

- Replace the satellite's external with the actual code on its
  trunk and point the Zope 3 trunk back to the package in the
  satellite project's trunk.

- Create a directory "version" in the Zope 3 tree that holds a
  "version.txt" file.  This will be the common version number
  that Zope 3 and the satellite projects share.

- Create an external in the satellite projects trunk
  that points to the version directory in Zope 3's trunk.

- Set the version.txt file to read "3.4.0b1". This will always
  read the next version that is going to be released.

- Change the setup.py for the satellite projects to read their
  version number from version/version.txt

In this setting we can develop the satellite projects on their own and
make releases that match the code.

As soon as code for a project moves from the Zope tree to the project tree, then the project can use whatever version numbers it wants as long as they are increasing.

So I think you should omit the last 4 steps above.

You also need to add externals in the Zope 3 tree that point to the new locations. This assumes that the 3.4 releases will be made from the Zope 3 tree or that you want to support development with the Zope 3 tree at least a while longer.

Future releases

When releasing Zope 3 "the large project" as beta 1 in this case,
following steps would be involved to keep the projects in sync:

- Create a release tag on the satellites (tags/3.4.0b1)

- Create a release tag on the Zope 3 trunk (tags/3.4.0b1)

- Update the `version` external on the tagged satellites
  to the tag of the Zope 3 trunk

- Update the Zope 3 tag to refer to the release tags on the

- Increase the version number on the Zope 3 trunk to `3.4.0b2`

Note: When deciding that we don't target b2 anymore but c1, we can just
update the trunk at any point in time. I don't expect any hassles from
that change. Most important thing is that the version.txt on the trunk
is monotonically increasing.

No. Each project should have it's own release number.

Support scripts

As we are dealing with more than 90 eggs here, we'll also need script
support to keep the handling of the synchronized satellites bearable.

I'll expect to need following scripts:

- Transform the current source tree into the "synchronized
  satellites" approach (one time thing)

- Do a release tag of the Zope 3 tree that includes the mechanics
  of updating the externals as described in the section 'Future
  releases' (needed in the future)


For those scripts I'll need to maintain a list of those synchronized
satellite projects that needs to live somewhere. Not all zope.* and
zope.app.* projects are satellites, just because they are referenced as externals from the Zope 3 tree (e.g. zope.testing is not) so I'm afraid
I'll need to put an explicit list somewhere.

No synchronized versions please.


Jim Fulton                      mailto:[EMAIL PROTECTED]                Python 
CTO                             (540) 361-1714                  
Zope Corporation        http://www.zope.com             http://www.zope.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to