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 > _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )