Release Policy for SchoolTool / SchoolBell
==========================================

The current version of this document is always at http://source.schooltool.org/svn/trunk/schooltool/doc/release-policy.txt.

The current release manager is: Brian Sutherland <jinty@web.de>

This policy tries to describe the way that the current release manager performs
a SchoolTool / SchoolBell release. It's purpose is to make the process open and
clear. It is also under continual review.

Security
--------

All publicly released files will be accompanied by text file containing the
md5sums of all files released at that time. This md5sum file will be signed by
the release manager's GPG key.

Nomenclature
------------

A good definitions for bug severities can be found at
http://www.debian.org/Bugs/Developer#severities.

Release blocking bugs are bugs for which are severe enough to delay a release
candidate being tagged, these include:

*   Database upgrades are working and tested.

And, for the SchoolBell 1.0 release:

*   Zope 3 transition is complete.

Including Patches in the Release Tree
-------------------------------------

In order to stabilise for the release in a way which has minimal impact on
on-going development, a branch will be made of the current trunk and release
candidates made for testing.

Once the release tree has been branched, the standard way for a patch to be
included is:

* commit the patch to trunk
* notify the release manager by mail or a reply to the schooltool-checkin mail

Patches are expected to address only one issue and well explained.

The standards by which a patch is judged for inclusion depend on a mixture of 2
factors, the severity of the bug and the risk of the patch causing other
breakage. For example, documentation patches will be accepted at any time, as
will patches which address grave bugs. Completely new features (wishlist bugs)
will never be accepted. As the release procedes, the bar required for patch
acceptance gets higher (Explained better in `Release Process`_ below).

Release Process
---------------

If the release is time based, the following timeline is followed:

1.  Branching

    On the date of the release, a release branch is made of the current trunk.
    The objective at this point is to clean up any major issues left before the
    release candidates can be given (Release blockers).
    From this date, the kinds of patches that will be accepted are:

    * Fixing important or worse bugs.
    * Incomplete feature removals.

    Patches that will *NOT* be accepted:

    * Last minute feature completion

2.  Release Candidates

    Once the release blocking issues are solved, a release candidate is tagged
    from the branch. From this point on, only serious bugfixes or low risk
    patches are accepted. Documentation or page template patches are examples
    of low risk patches.

3.  Release

    After some time and testing, the release is made by tagging the release
    branch as final. After this point, only grave bugs or security fixes are
    accepted.

4.  Bugfix Release

    In most cases, when a grave or security bug is fixed, a release will be
    made with an extraversion, e.g. 0.9.1

Zope
----

Currently, portions of a Zope X3 checkout are included in the releases. This
has implications for the release:

* A minimal set of Zope X3 libraries will be included with SchoolBell releases
  but not with SchoolTool releases.
* Between SchoolBell releases, the revision of the Zope X3 checkout will be
  pinned to the one released with the last version of SchoolBell.
* A few weeks before the next SchoolBell release the revision will be
  incremented to the current version of the Zope X3 trunk or the Zope X3.1 tag.

This will happen until Zope X3.1 is widely available, after which Zope
libraries will not be released with SchoolBell and compatibility will be
maintained with released versions of Zope.
