RE: RFC: Proposed backward-compatibility policy
Jim, I think this is a very fair and gentle policy for any kind a programmable product, and an extremly fair policy for an open source product (where I can check and/or modify the source if I run into a crucial compatibility problem). You probably have to explicitly exclude the environment of external methods, and restrict compatbility to the published APIs ("published" being easier to define in Zope 3 than in Zope 2, I assume). Best regards, Martin _______________________ COMIT Gruppe Risk Management Systems http://www.comit.ch http://www.quantax.com - Quantax Trading and Risk System http://www.swordrisk.com - Sword Operational Risk System
Gfeller Martin wrote:
Jim,
I think this is a very fair and gentle policy for any kind a programmable product, and an extremly fair policy for an open source product (where I can check and/or modify the source if I run into a crucial compatibility problem).
You probably have to explicitly exclude the environment of external methods,
Why do you say that?
and restrict compatbility to the published APIs ("published" being easier to define in Zope 3 than in Zope 2, I assume).
Defining what's "public" is definately a challenge. Zope 3 is farther along here, but there are still issues. This issue is the motivation for the "testing" paragraph in the proposed policy. Rather than asking the Zope developers to know what people are relying on for sure, we are going to rely on people catching problems during testing. Developers will make reasonable guesses, but they have some freedom to take risks, relying on people to tell them if they've broken something. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
participants (2)
-
Gfeller Martin -
Jim Fulton