Below is a proposed policy on backward compatibility for Zope. Zope Policy on Backward Compatibility ===================================== Backward compatibility needs to be a very high priority. Clean software also needs to be a high priority. Unfortunately, these goals are often at odds. Providing backward compatibility support makes code more complex and, thus, less maintainable. Going forward, we will address these conflicting goals in the following ways; 1. During development, alpha testing, and beta testing of new releases, any backward-incompatible change will be considered a bug. That is, we will make all effort to make sure that each release of Zope is backward compatible with the previous two feature releases. 2. Backward compatibility support will be limited. When we make a change that would require a change in software or data, we'll add code to support the old software or data, but we will also add code to generate deprecation warnings when that support code is used. The deprecation warnings will say specifically when the backward-compatibility support will go away. This time will usually be expressed as a release number at least two feature releases past the next feature release. (For example, if the next feature release is release 3.1, then the backward compatibility support would not be removed any sooner than release 3.3.) In other words, we will limit the time extent of backward compatibility support, but we will give plenty of warning. When data changes are involved, we'll provide data conversion tools that will be available before we begin the deprecation process. An additional issue is that it is often difficult to figure out if subtle features are being used. (For example, a change in an exception base class might affect some client that expected to catch the exception based on it's base exception.) It is very hard for a developer to assess whether any applications are relying on a particular feature and thus whether backward-compatibility support needs to be provided. Often developers will make judgment calls. If they judge wrong, we need to catch this with testing. This leads to a 3rd point: 3. It is very important to catch backward compatibility problems during development of new releases. In particular, it is important to test new Zope releases before they are released in final form. If a backward-compatibility problem is found before the final release, it will be considered a bug and will be fixed (by adding backward compatibility support) if at all possible before the final release. After the final release, we may choose not to bother to fix backward-compatibility problems. Consumers of Zope have a right to backward compatibility, but they also have a responsibility to test Zope against their applications during the beta release cycle (or sooner) to make sure their applications work. Questions? Thoughts? 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