[Zope3-dev] [URGENT] Organising the satellite projects, eggs and version numbers before beta today

[Jim Fulton]

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

> Hey,
>
> 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:
>
> Problems
> ========
>
> 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
> icky:
>
> - 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.



>
> Proposal
> ========
>
> 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
>   projects.
>
> - 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
>   satellites.
>
> - 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)

YAGNI

>
> 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

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org