-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roger Ineichen wrote:
Hi Tres
Betreff: Re: [Zope-dev] Deprecate ITerms in zope.app.form? [Re:zope.browser?]
[...]
If we that there is a real goal other than "future cleanliness" for the deprecation system, then a system which requries warnings to be explicitly enabled (e.g., via a tool, or an environment variable, or something) would help reduce the burden on the downstream developer.
I think it's more then "future cleanliness". My goal is to reuse as much as we can. This means, if we deprecate "zope.app.form.browser.interface.ITerms". And other developer will follow this refactoring and implement some nice components which provide some ITerms goodies. We can use this new addon packages in zope.app.form free projects.
If they ignore our cleanup and will still import the ITerms from zope.app.form.browser.interfaces. We can't use this packages without the get the dependency back. And that hurts.
I think such cleanup ar not optional and only a nice thing. Such cleanup allow us to participate on the same base.
And since BBB support is given (with a minimal deprecation warning sideeffect) I think this is the best what we can do.
You lose the reusability of any existing packages which supply the "old" interface / location once you finally remove the interface from the deprecated location. Unless their maintainers issue new versions of their packages (as Fred did in my example, to keep from sleeping outside with Dino in ;), your code will not be able to use both the new version of the framework *and* the old plugin at the same time. "Refactor mercilessly" is a mantra of a methodology which is specifically focused on building applications, rather tha libraries / frameworks. Once you have "downstream" users who are not actively involved in the development of your package, the costs of refactoring go up. As an example from outside Zope land: Linux developers fiercely defend their practice that there is no stable "ABI" in the kernel; out-of-tree modules have to be recompiled to be compatible with new kernel versions, including refactorings, etc. However, they are equally fierce in the policy that a user-space API, once released, is maintained *forever*. User-space code which uses such an API *must* continue to work. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iD8DBQFJTYlG+gerLs4ltQ4RAqd7AKCpf4om3G6gpx0ilfiw1/83JgoxUgCgjBBP GBHZ4dF3Ts2UmVWKEZD5+IE= =RCah -----END PGP SIGNATURE-----