[Zope3-dev] tracking satellite project's trunks
Jim Fulton
jim at zope.com
Fri May 4 02:43:19 EDT 2007
On May 3, 2007, at 1:24 PM, Fred Drake wrote:
> On 5/3/07, Christian Theune <ct at gocept.com> wrote:
>> Right. However, my suspicion would be that whoever makes a change
>> to the
>> trunk on a satellite shouldn't have to go to the Zope 3 trunk.
>
> That's true regardless of how the Zope 3 checkout references the
> satellite project's code.
>
>> Also, maintainers of the Zope 3 tree shouldn't have to read every
>> commit
>> message to update the reference (doing so would be pointless, that
>> what
>> not pinning the external is for).
>
> That's fine too. The maintainers of the Zope 3 tree simply need to
> decide how the externals in the tree need to be made. As I said, I
> don't care which they choose.
My advice to the maintainers of the Zope 3 tree is to:
1. in the long term, stop maintaining the tree and switch to a meta
project as Tres suggested. :)
2. depend on fixed versions, either by egg dependency or externals
with tags or revisions.
To update to newer versions, they don't need to follow each project's
commits. They could just periodically update to the newest version
and test. A variation on this is to update to newest versions
periodically and, for things that change, scan the changes. I expect
that, over time, most projects will change very infrequently.
Also, I would hope that when individual project releases are made,
that the releasers will do a reasonable job of updating change logs.
This should give consumers a high-level summary of changes that are
easier to consume than individual.
>> When moving to a release of Zope 3 we should update those
>> externals to
>> specific revisions or tags though. (Tags being preferred IMHO as
>> we only
>> want software of at least the same degree of stability, right?)
>
> That sounds like Zope 3 maintainers want to make decisions about the
> release cycles of the satellite projects. That's bad.
>
> Saying that Zope 3 as a whole is "stable" (whether that's by making a
> release with an X.Y number or anything else) is about the state of the
> Zope 3 tree at that point; part of that is an assertion about anything
> that's included by an external or by a requirement that it's stable as
> used from Zope 3. It has nothing to do with the release cycle of the
> independent projects, and should not force a numbering change. It's
> fine if a new tag is generated, but tags in satellite projects that
> aren't for that project's release cycle should include the name of the
> project whose cycle is involved. For example, if there's no
> zope.index release corresponding to the Zope 3.4b2 release, it's fine
> to create a Zope-3.4b2 tag of the zope.index project.
Well said.
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
More information about the Zope3-dev
mailing list