Release Noting Guide

The following is a guide for anyone who needs to work on the release notes of Bugzilla which appear at docs/rel_notes.txt.

Release notes can be inserted as a part of a patch, especially if you are willing to follow the appropriate style. The person responsible for the release notes may end up changing what you wrote.

Typically however people are forgetful, so release notes are updated by the release noter towards the end of the development cycle. The release noter will attempt to discover what has been forgotten.

If you are not the release noter, to ensure things are release noted it is generally easier to comment on the release notes bug for this development version (search for “release notes”) than create actual patches.

General Style Issues

Please attempt to follow the existing style of the release notes. In particular, this means:

Updating Release Notes Before Release

The following gives a list of tasks that should be performed on the release notes before release:

Updating Release Notes After Release

Once you have released, there are a few tasks you should do to prepare for the development version:

Stable Point Releases

Stable point releases are generally done on branches, and hence their release notes can fork from those on the trunk.

However, administrators often jump from stable point releases up to the next stable major release, so you need the trunk to indicate what has changed since the point releases.

Hence, please ensure that the release notes are brought from the branch to the trunk. You should place the section for that version before the one for the current development version.

Furthermore, check that there aren’t existing notes in the development version section that instead apply to the stable point release section. If so, move them there. If there is an similar note already in the stable point release section, consolidate them there.