> So for Zope 2.8 this means to me:
> - the ZConfig and zdaemon should have a minimal release management
> (means stable released should be tagged properly)
> - ZODB development can be done against any version
> - ZODB releases should done against a dedicated ZConfig, zdaemon
> release (means something tagged)
More generally, all releases of all projects P should be done against
tags of all P's external dependencies.
> - the local copies of ZConfig, zdaemon in Zope 2.8 will replaced by
> svn:externals (using a dedicated tag)
Wnen tags for those exist, I'll change ZODB to use them too.
> The ZODB in 2.8 is currently not an svn:external but a local copy as well?
No. Do you ever use SVN <wink>? Go to a shell right now, cd to the
root of a Zope 2.8 checkout, and type:
svn proplist -v utilities lib/python
The 9 svn:externals properties you get back containing
"ZODB/tags/3.4.0a9" define exactly how Zope 2.8 obtains ZODB. When
you do "svn up", this is why you see message go by saying things like
Fetching external item into 'lib\python\ZEO'
Fetching external item into 'lib\python\ZODB'
Zope3 also uses svn:externals to obtain ZODB, but only stitches in 6
directories from ZODB (as opposed to the 9 ZODB directories Zope 2.8
> It might also make sense to tag ZConfig+ZODB together since ZODB
> depends on ZConfig.
This doesn't make sense to me, although I'm not sure what you mean.
Zope, ZODB, ZConfig, and zdaemon are 4 independent projects. Zope and
ZODB both depend directly on ZConfig, and both also depend directly on
zdaemon. Zope also depends on ZODB. It would be _prudent_ for Zope2,
Zope3, and ZODB to use the same versions of ZConfig and of zdaemon.
That would be much easier to do if ZConfig and zdaemon were tagged.
The first time ZConfig and zdaemon get tagged, it's important that
whoever do that first search all clients (ZODB and both Zopes) for
changes to those checked in from a wrong project, and do merges back
to ZConfig and zdaemon (I explained that dance last time) -- else
those changes (if any) will get lost.
Zope-Coders mailing list