[Zope-dev] RFC: Proposed backward-compatibility policy
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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
Re: [Zope-dev] RFC: Proposed backward-compatibility policy
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 )
Re: [Zope-dev] RFC: Proposed backward-compatibility policy
On Oct 27, 2004, at 15:49, Jim Fulton wrote: Below is a proposed policy on backward compatibility for Zope. Zope Policy on Backward Compatibility = snip +1, even regardless of its actual content. Having a policy at all is a lot better than the I gotta ask X people policy that seemed to be in use so far. jens ___ 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 )
Re: [Zope-dev] RFC: Proposed backward-compatibility policy
Chris McDonough wrote: 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. I'd actually like to set up a public buildbot server somewhere that we could automatcally test 3rd-party applications with. We could then test a variety of applications. ZC doesn't really have the human bandwidth to manage another machine in the zope.org cluster. Would anybody be willing to run a buildbot server? We (Fred :) can help set it up, as we've done that here in F12g. If we can get the server going, then we'd also need volunteers to run buildbot slaves. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
Re: [Zope-dev] RFC: Proposed backward-compatibility policy
En/na Jim Fulton ha escrit: Chris McDonough wrote: 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. I'd actually like to set up a public buildbot server somewhere that we could automatcally test 3rd-party applications with. We could then test a variety of applications. ZC doesn't really have the human bandwidth to manage another machine in the zope.org cluster. Would anybody be willing to run a buildbot server? We (Fred :) can help set it up, as we've done that here in F12g. If we can get the server going, then we'd also need volunteers to run buildbot slaves. Jim Hi, I also think the Policy you propose will be a goal. We have no resources to run a bulidbot server. Moreover, nowadays we haven't enought human resources to develop on zope head (I really hope this can change in a near future). So, our products are susceptible to break between Zope releases. What I can just ensure is we will test our products with every beta release of Zope (or alpha release, if any) as soon as possible, in order to detect and try to solve problems before final releases. Regards Santi Camps http://www.earcon.com ___ 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 )
Re: [Zope-dev] RFC: Proposed backward-compatibility policy
Maybe we should have a bw compat category in the collector(s) for this to make it easy to find bw compat issues. It would make it easy to get a list of showstopper issues around release time. - C On Wed, 2004-10-27 at 14:22 -0400, Jim Fulton wrote: Andreas Jung wrote: --On Mittwoch, 27. Oktober 2004 9:49 Uhr -0400 Jim Fulton [EMAIL PROTECTED] wrote: 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. Consumers of Zope have a right to backward compatibility Consumers of Zope also have the duty to test beta releases! A lot of people are waiting the final release before trying it for a variety of reasons. So why do be do beta releases? :-) Exactly. If people want more frequent releases, which they do, and they want higher quality, then they need to help by testing. We need to make this clear. This is an important way that people can contribute. 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 )
Re: [Zope-dev] RFC: Proposed backward-compatibility policy
Chris McDonough wrote: Maybe we should have a bw compat category in the collector(s) for this to make it easy to find bw compat issues. It would make it easy to get a list of showstopper issues around release time. Great idea! Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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 )
