[ZODB-Dev] RFC: Proposed backward-compatibility policy

[Jeremy Hylton]

On Wed, 27 Oct 2004 12:53:44 -0400, Jim Fulton <jim at zope.com> wrote:
> 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.4, then the backward compatibility
>     support would not be removed any sooner than release 3.6.)  In
>     other words, we will limit the time extent of backward
>     compatibility support, but we will give plenty of warning.

How does this apply in the near term?  The cat is already out of the
bag for 3.3, which probably isn't fully backwards compatible.  Would
you consider those bugs that would be fixed in a 3.3 maintenance
release?  For example, I don't think the ZEO protocol for 3.3 isn't
compatible with the ZEO protocol for 3.2.  In addition to data and
code, it might be worthwhile to say something in the policy about zeo
protocol compatibility.

> 3. It is very important to catch backward compatibility problems
>     during development of new releases.   In particular, it is
>     important to test new ZODB 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
>     ZODB have a right to backward compatibility, but they also have a
>     responsibility to test ZODB against their applications during the
>     beta release cycle (or sooner) to make sure their applications
>     work.

Does this mean that consumers who depend on subtle features are out of
luck if they don't test the alphas or betas?  I think that may be the
only practical thing to do.  There are too many under-documented
corners of ZODB to be thorough about testing without help from users.

On the whole, this seems like a very reasonable approach.

Jeremy