Am Donnerstag, den 03.05.2007, 08:55 -0400 schrieb Fred Drake: > On 5/3/07, Christian Theune <[EMAIL PROTECTED]> 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.
I'm building up on a comment by Jim who wanted to keep those synchronized. If we don't want that then the effort for keeping them synchronized would go away of course. Many things in this proposal are an effect of that requirement. > > 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. Same as above. ;) Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
