Zope Release Policy

Introduction

There are several groups to whom an understanding of the workings of the Zope release cycle is important.

• The Zope user community

  The community wants to know what to expect from product releases in terms of features, fixes, stability and backward compatibility. As the community becomes a more active participant in developing the Zope code, they will also need to have some understanding of our company goals and how they influence the release policy in order to most effectively coordinate their work with our own.

• DC consulting customers

  Consulting customers need to know that their projects are being delivered on a stable platform and need to be able to anticipate what their maintenance strategy will be going forward in terms of software updates.

• DC consulting project managers

  Project managers at DC need to be able to coordinate their customer projects with the Zope release cycle to be able to deliver projects for consulting customers on stable releases. They also need to be able to advise customers on maintenance strategy after delivery.

• DC product managers

  Product managers at Digital Creations need to coordinate planned development of the Zope platform and set expectations for delivery.

• Zope developers

  Internal developers and (soon) active community members with checkin priveleges need to understand the release policy and the mechanics that support it in order to coordinate their development projects.

Goals of the release policy

• 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.

• 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.

• 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.

• 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.

• 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.

• 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, DC 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.

There is a companion to this this document that describes the mechanics and conventions for working with the Zope code in activity branches.

The second key to allowing frequent releases and avoiding contention is for product management at DC to refrain from promising specific new features for particular Zope releases. Promising feature sets for specific releases puts us at risk of having to delay a release needed to support a consulting project or other important issue in order to keep our promise. Infrastructure projects driven by product management should have their own plans and milestones that are not tightly coupled to the Zope release schedule.

Created by Brian. Last modified on 2000/07/06.