[Zope3-dev] tracking satellite project's trunks

[Fred Drake]

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.

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


  -Fred

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