TWiki Release Process
This topic is the executive overview and gateway for documentation that describes the technical
processes used to build TWiki releases.
TWiki source code is revision controlled in a Subversion
TWiki release numbering uses three numbers: major
- 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
. All other extensions follow their own release cycles as dictated by their developers.
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
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
. 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
for all aspects of TWikiReleaseManagementProcess
for other TWiki process documents.
-- Contributors: CrawfordCurrie