Log in
Forgot your password?
History for ZopeReleasePolicy
??changed:- The Zope Release Policy Introduction It is important for all of the Zope developers (internal and external) to understand the Zope release policy, as it affects how and when developers work on the source code and generally coordinate their projects. Goals of the release policy o **Formalize expectations for Zope releases** The release policy should document the naming convention for releases and how names relate to release content, quality, level of testing, and backward compatibility. o **Deliver customer projects on stable, supported releases** The release policy must make it possible to ensure that customer projects may be fielded on stable public releases. o **Allow both product management and customer projects to push the platform forward** It should be possible for the fruits of both planned development work and consulting engagements to be incorporated into regular Zope releases. The policy should ensure that the goals of both consulting project managers and Zope product management may be achieved in a largely independent way. Zope software releases To ensure that regular Zope releases can be made that accomodate the goals of the product plan, the community and consulting project managers, we have adopted a release methodology that allows us to avoid contention between those sets of goals. Zope releases are named using a three number naming convention: *major revision*, *minor revision* and *bug-fix* revision. The meaning of each number in the release name are outlined below. o The first number is the *major revision* and changes very infrequently. Major revision releases may contain major architectural changes and may not be backward compatible with existing code or data. Major revision releases may require data and/or code conversion in order to upgrade (though we of course try to avoid this as much as possible). Major revision releases are driven by product planning. Major releases go through an alpha release where glaring problems are resolved and final features are added. A possibly lengthy beta period follows where no new features are added, bugs are fixed and testing is performed both internally and by use in the Zope community. Successive beta releases are made until the software and any associated upgrade tools and documentation are deemed stable. o The second number is the *minor revision* and changes on a fairly regular basis. An minor revision release may contain new features driven by Zope product planning and / or new features resulting from consulting project work. Minor revision releases *may* in rare cases contain minor backward incompatibilites, though we try hard to avoid this unless absolutely necessary. Minor revision releases go through *at least* a short beta period before final release. Depending on the scope of the changes for the release, there may be an alpha release before the beta if it is deemed necessary. During the beta period no new features are added and bugs are fixed. Testing for an minor revision release consists of internal testing by DC and community coverage during the beta period. Successive beta releases are made if needed until the software is deemed stable and a final release is made. o The third number is a *bug-fix revision* and changes on an as-needed basis. Bug-fix releases contain only bug fixes and should always be backward compatible. Bug fix releases do not go through an alpha or beta release, though they are tested internally with a focus on verifying the bug fixes made for the release. In the future, ZC may consider a strategy for managing some of the major pieces of Zope as separate "components" that may have their own release cycles independent of the overall Zope release cycle. This would allow greater flexibility for the individual development of different components of Zope while still allowing allowing them to be incorporated into the main Zope release cycle. Because the development process mechanics that support the release policy now allow for more frequent releases, the need to evolve individual components separately may not be such a problem. We may revisit this in the future. Impact on the development process To implement this policy effectively, developers (both internal and external) will need to follow some general rules and be aware of some basic mechanics of the release process when working on the Zope code. In the past, we made alpha releases from the "trunk" in CVS, and at the time of the first beta we created a new branch for the given release (say, 2.1.0). So a branch would be created reflecting 2.1.0b1 and all further development on the 2.1.x series through final release and beyond into maintenance would need to be done on the 2.1.0 branch. Immediately after the branch was created, many major surgeries would often begin on the trunk and it would take a lot of time and effort to get the trunk back to a relatively stable state in order to make the next (non-bug fix) release. This approach caused a lot of problems because it was difficult to orchestrate releases when they were needed by various parties and the goals of product managers and consulting project leaders often became at odds with one another. One of the keys to supporting a process that allows frequent releases is ensuring that when major surgeries happen, they happen in a way that does not block the release cycle. This means that no actual development work may happen on the Zope "trunk" in CVS. All development activity should happen in branches and only be merged into the trunk when the work is stable enough to be included in the next beta release. *The trunk should never be in a state where we would be uncomfortable making an alpha or beta from it on 2 days notice*. We will provide a companion to this this document that describes the mechanics and conventions for working with the Zope code in activity branches. (See the ZopeCVSFAQ).