[Zope] RFC: Proposed backward-compatibility policy

[Jim Fulton]

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 at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org