[Zope-dev] Re: [Zope 2.11] KGS incomplete (Was: Stepping forward and going beta)

Andreas Jung lists at zopyx.com
Sat Dec 29 02:36:56 EST 2007



--On 29. Dezember 2007 08:17:43 +0100 Hanno Schlichting 
<plone at hannosch.info> wrote:

> Andreas Jung wrote:
>> --On 28. Dezember 2007 17:56:20 +0100 Hanno Schlichting
>> <plone at hannosch.info> wrote:
>>> Now all of those above packages aren't in the beta1 tarball. I'd
>>> consider this a bug, right?
>>
>> I removed the externals so they are not in the b1 tarball. Possibly
>> a bug from the deprecation point of view. On the other side it is hard
>> enough now to keep track of the "right" version and dealing with the
>> different versions. The KGS is a good start and I wrote a small script
>> keeping the Zope 2 svn:externals in sync (mostly) with the KGS. However
>> I need some additional metadata in order to know what deprecates when in
>> order for having a half-way automated mechanism for updating the
>> externals. I can not depend on the informal information coming from
>> mailing lists and private mail becomes the huge amount of externals
>> becomes unmanageable. The idea would be to extend the KGS or maintain a
>> database/file that contains for every component its deprecation release
>> (and perhaps other metadata needed).
>
> Adding those deprecated but still functional packages to the KGS would
> be one way, but seems to be a bit of work.

I just wonder what deprecation in the future means. There were some 
discussions about the "Zope 3 app server" and its future releases..one 
thought was that there would be no further releases of the Zope 3 app 
server but only independent releases of its modules. So each module has its 
individual lifecycle and no Zope 3 app server distro will give us the 
information that a particular module is deprecated. However a component
zope.mod1 could use zope.mod2 within some release and deprecate the use of 
zope.mod2 at some point in the future...this thought alone lets me shiver 
:-)

Back to the original problem, the zope.app.* modules. If those modules
are used by Zope 2 internally only then we don't need to include them.
If third-party products depend on zope.app (I have no idea if this is the 
case) then we must put them back...however there is a chance that these
older zope.app modules produce errors during the tests because of possibly
incompatibilities with newer modules. I have the strong opinion that 
zope.app is "something Zope internal" that should only be used by Zope 2/3
internal functionality and not by third-party apps...but perhaps I am 
wrong...no idea.

Andreas



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20071229/34f101ae/attachment.bin


More information about the Zope-Dev mailing list