History for ZopeDevelopmentProcess

++added:
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.