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

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

Questions? Thoughts?


Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714
Zope Corporation
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to