Tags:
process1Add my vote for this tag create new tag
, view all tags

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

  1. 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.
  2. 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)
  3. 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

  1. Translate the instructions for reproducing problems into a unit test or automatic testcase, if at all possible.
  2. Fix the problem
  3. 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"
  4. New functionality should never be marked "Patch", just bugfixes.
  5. 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.
  6. The bug is closed only when it has been released. the release manager will flip the status then.

Instructions for Releasers

  1. For major and minor releases, follow the standard BuildingARelease instructions always releasing from the relevant branch.
  2. For patch releases, see PatchReleaseMaintenanceSVN

See CategoryReleaseManagement for all aspects of TWikiReleaseManagementProcess.

See CategoryProcess for other TWiki process documents.

-- Contributors: CrawfordCurrie, SvenDowideit

Discussion

Edit | Attach | Watch | Print version | History: r25 < r24 < r23 < r22 < r21 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r25 - 2011-12-11 - GeorgeTrubisky
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.