ZopeDevelopmentProcess
Details of the Zope Developement Process
If you have read the CommitterGuidelines, you know the general rules that the Zope developers play by. But to avoid chaos, there is some detailed information that all committers need to know.
Bugs, Features and Where They Go
Zope development usually happens concurrently on two "branches", where one of the branches is often (but not always) the trunk.
Here is how it works: the next "feature release" is usually represented by the trunk. Substantial new features that have gone through the fishbowl process and been ok'ed by the owners of the affected areas get checked into the trunk (where they will be available when the next feature release is made).
Smaller features (minor things that do not affect UI or documentation in a way that justifies the weight of a whole fishbowl project) also are checked into the trunk, again, after ok'ing them with the appropriate owners.
In both cases, any features added should be noted in the CHANGES.txt in the trunk (not in the "current release branch" - more on that below).
At the time the first beta of the new feature release is made,
we create a new branch for that feature release (rooted at the
trunk at the time the first beta is made). For 2.8, for example,
I will create a branch named Zope-2.8
, and all further
checkins for the 2.8.x line need to go to that branch.
Because by definition a beta should be "feature complete", from this point on only bug fixes should go into the Zope-2.8.
At this point, the Zope-2.8 is considered the "current release branch". The trunk now represents the "next feature release" again (presumably 2.9).
This is pretty straightforward for features - it is a little more complex (and we have to be a little more careful about) bug fixes. As noted above, there are usually two branches that are under active development (the trunk and the current release branch). A bug fix needs to go into both the current release branch and the trunk (so that the bug does not reappear in the next feature release).
When you check in a bug fix, you almost always need to:
- Check in the fix on the current release branch
- Note the fix in the /doc/CHANGES.txt on the current release branch
- Merge the fix to the trunk to be sure its fixed for the next feature release
Note that you don't need to note the fix in the CHANGES.txt on the trunk if you don't want to. At the time a new feature release is made, we merge the items in CHANGES.txt from the trunk and current release branch so that for any given release it notes the actual changes as of that release.
How Release Affect The Process
Even if a bug fix is a nobrainer, all committers still need to be aware of what is going on in the release process before just checking something in. For example, our goal is that no changes are made between the final beta and a release.
If we are in the final beta of 2.8.1, for example, no one should be doing commits on the Zope-2.8 branch until the final release is made. That doesn't mean you can't fix bugs, just that you may have to do them on a private activity branch that week and merge them after the release
The release manager for a release will let committers know via zope-coders when an event that all committers need to know about (like a release) is imminent. It is the responsibility of all committers to pay attention to prevent causing problems with releases.
What About Older Releases?
One question that arises here is: "what about fixing bugs in back releases"? That is sometimes a valid thing to want to do, but to date we have only actively maintained the trunk and the current release branch. The reason for that is mainly due to overhead and resource availability.
Ideally, we could backport important bug fixes to older versions and make occasional bug-fix releases of those older versions. In reality, we don't have the resources (internally at ZC) to commit to that. It also imposes a greater (possibly much greater, depending on the goal) burden on every committer who checks in a bug fix. As we continue opening the development process to the community, this could become a possibility if people are found who can commit to the effort required to coordinate the maintenance of older releases.