-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote: > Hi there, > > Tres Seaver wrote: > [snip] >> Actually, we don't need an upgrade path. We can just leave a >> 'meta.zcml' in zope.component which <includes> the new locations. That >> file will be *inert*, and doesn't therefore need testing, because none >> of the directive implementations will be present. >> >> Over time, people can shift to including the new meta.zcml at their >> leisure. We can leave the redirecting meta.zcml in zope.component >> *forever*, if need be. > > It's not just the meta.zcml story, where I can agree we could leave > something in place, but it's the dependencies in setup.py, right?
Right. Dropping any dependency on zope.configuration, zope.security etc. *will* happen. The folks affected by such a change will be those who rely on the current transitive dependency graph to pull in those pacakges: they will need to update their versions.cfg / setup.py, etc. in order to pick up the new version of zope.component. See below for the documentation required. > If the implementation of the directives lives in zope.componentzcml, any > codebase that loads any ZCML at all (in its tests especially) is very > likely to need zope.componentzcml besides zope.component. Or am I > missing something here? It needs to have it importable, yes (so that the redirected meta.zcml works). Come to think of it, we could even leave the extras in place for BBB, since anybody who has been relying on the transitive graph has to be depending on 'zope.component[zcml]' already, right? I don't have a problem with leaving it in place as a pure dependecy shim. > [snip] >>> Anyway, this upgrade path needs to be spelled out clearly in the >>> zope.component CHANGES.txt pointing people in the right direction. We >>> also need to spell it out in this document: >>> >>> http://svn.zope.org/zope3docs/source/migration/34to35.rst >> Maintaining that document is out of scope for me. ;) > > If my above story about the dependencies is right, it is necessary to > remark this in a central place. We do have framework-wide policies in > place, and explaining to people how to unbreak their code in a single > place they can look should be one of them. We do after all have people > who use a whole bunch of these libraries at the same time. But if you > can write it clearly in the CHANGES.txt and tell me, I'll add it to that > document if you can't be bothered. It isn't that I can't be bothered: I'm don't want to reinforce the idea of a new monolithic release labeled "3.5" to which people will upgrade from the current "3.4" in lockstep. Not only do I not want to *use* such a monolith; I'm convinced that trying to maintain it can impede (and has impeded) develpoment of the actual bits which make it up. I won't do anything active to defeat your efforts in that direction, but I don't want to help on that part. In any package where I create a backward incompatibility, I will certainly document it clearly, with instructions on how to update dependent packages. Putting the canonical docs in the package is an absolute necessity for reuse of the package outside any larger package set, anyway. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJsUeQ+gerLs4ltQ4RAihbAJ4gwRemxOz7/CT/wQUpkLEd++EQFgCfUHm6 0i2xCkbvckMB/pp59ezpCKk= =n7Fv -----END PGP SIGNATURE----- _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )