TWiki Release Process
This topic is the executive overview and gateway for documentation that describes the
technical processes used to build TWiki releases.
Some terminology
TWiki source code is revision controlled in a
Subversion repository.
TWiki release numbering uses three numbers:
major .
minor .
patch
- An increment to the major part of the numbering may involve users in a significant amount of work to upgrade to, but the reward will be significant improvements.
- The minor part will normally be a seamless upgrade not involving any data compatibility issues. It should normally be a collection of bug fixes and relatively minor functionality increments (e.g. addition of new APIs)
- The patch part will be used for individual bugfixes and collections of bugfixes. A patch release will not involve users in any reworking of content or data.
When we talk about "Releases" we mean the TWiki core + the standard extensions listed in
tools/MANIFEST
. All other extensions follow their own release cycles as dictated by their developers.
major and
minor releases will come from the main branch.
patch releases will come from the branch for the relevant release, which should have been created when the release was built.
How to tell what's planned for the next release
New features are raised and tracked per
TWikiReleaseManagementProcess
The
Bugs web is where we track agreed features and all bugfixes.
A bug report has a three-setting "TargetRelease" radio button in it, with the levels
major,
minor and
patch. This is used to mark reports as planned for inclusion in the next relevant release, and is only relevant when the Item status is "WaitingForRelease". Reporters should
not touch these settings - they are used for planning and release management by developers and releasers only. Reports may have their release changed in release meetings or by the release manager. The flag is used to generate release notes for the relevant release levels.
Bug lists for release notes are automatically generated in
Bugs:ReleaseNotes
Instructions for Developers
- Translate the instructions for reproducing problems into a unit test or automatic testcase, if at all possible.
- Fix the problem
- When you fix a bug in core or standard plugins that needs to be included in the next patch, then set "TargetRelease" to "Patch" when you set the bug to "WaitingForRelease"
- New functionality should never be marked "Patch", just bugfixes.
- Bugs not in the core or standard plugins (i.e. in other extensions, or related to the bugbase) should not be marked "WaitingForRelease". Use "Closed" instead.
- The bug is closed only when it has been released. the release manager will flip the status then.
Instructions for Releasers
- For major and minor releases, follow the standard BuildingARelease instructions always releasing from the relevant branch.
- For patch releases, see PatchReleaseMaintenanceSVN
See
CategoryReleaseManagement for all aspects of
TWikiReleaseManagementProcess.
See
CategoryProcess for other TWiki process documents.
--
Contributors: CrawfordCurrie,
SvenDowideit
Discussion