[Zope-dev] RFC: Proposed backward-compatibility policy

[Chris McDonough]

This sounds good.  I would add perhaps the concept of a 'smoke test'
application for backwards compatibility testing.

For Zope 2, the smoke test might be Plone or another large app written
on top of it.

Maybe someone involved in Zope 2 release management would volunteer to
run the "smoke test app" unit tests on each proposed Zope 2 release.  If
the unit tests didn't pass, it would block the release until the issue
was resolved.  I think Andreas does this in a sort of ad-hoc way with
Plone now but not sure.

Same for Zope 3, I just don't know what the smoke test app would be.

- C

On Wed, 2004-10-27 at 09:49 -0400, Jim Fulton wrote:
> 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
>