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.
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
> 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?
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -