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

Fred Drake fdrake at gmail.com
Thu May 3 08:55:40 EDT 2007


On 5/3/07, Christian Theune <ct at gocept.com> wrote:
> I'm in front of the same wall that Fred was going up. ;)

And I ran up against a related issue again on Tuesday, which I've not
had the time to write up.

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

+1 -- The sooner, the better.

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

Once the code is in the satellites, there's no reason for them to
share version numbers.  Ever.  They can all start off with "3.4b1",
and go from there.  The goal is to separate the release cycles.  I'm
fine with that being "complete" for 3.4 final, but I certainly don't
want the satellite projects to be tied to the Zope 3 trunk at all.

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

-1 -- The dependency relationship should be one-way.

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

-1 -- Just the version number for the satellite, please!

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

Tying their version numbers to Zope 3 doesn't affect this.

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

-1

The branched/tagged Zope 3 should refer to specific
tags/branches/revisions of the satellites, but the satellite projects
should not be affected by Zope 3 releases.

> I'll expect to need following scripts:
...
> - 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)

This should not be needed, because the satellite projects should not
be affected by subsequent Zope 3 releases.


  -Fred

-- 
Fred L. Drake, Jr.    <fdrake at gmail.com>
"Chaos is the score upon which reality is written." --Henry Miller


More information about the Zope3-dev mailing list