--On 29. Dezember 2007 08:17:43 +0100 Hanno Schlichting <plone@hannosch.info> wrote:
Andreas Jung wrote:
--On 28. Dezember 2007 17:56:20 +0100 Hanno Schlichting <plone@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