Subversion Branching and Tagging

Overview

  • A major release is a release where the first digit in the version number changes.
  • A minor release is a release where the second digit in the version number. Patch releases changes the 3rd digit.
  • A patch is a release of a set of changes to a previous software release that fixes one or more problems with that release. Patch releases are released as complete packages for new installations and cumulative packages with all the changed files since last major/minor release. (The idea is that an admin with a running installation can always simply copy the contents of a the package with the changed files on top of the installation without having to have installed all the previous patch releases that have been released since last major/minor release.)
This is the release process:
  • All development of major/minor releases and all extensions is done in the Subversion /trunk/.
  • The first major/minor release is built from a new patch branch which is created soon after the release meeting agrees to declare feature freeze.
  • It is a strict criteria that the new Patch branch is not created until ALL agreed features are implemented. We do not create the Patch branch in the middle of the implementation of complex features. This means that in the short period between declaration of feature freeze and the creation of the feature freeze the feature freeze also includes the /trunk/.
  • In the period between the creation of the Patch branch and the minor/major release all bug fixes to the core code and default extensions need to be checked into both the /trunk/ and the new Patch branch.
  • New features are only checked into the /trunk/. Checking in new features into the /trunk/ is allowed again the minute the new Patch branch is created
  • Each time an actual release is created (major/minor/patch) a tag copy is created in Subversion.
  • The naming convention:
    • We name the branches Release01x00, Release02x00... in branches
    • We name the tags Release01x00x00, Release01x00x01, Release01x00x02.... in tags

More details on the release process

  • The Release branch is always created from /trunk/. All major development happens on /trunk/ which also holds the extensions repository. The Patch branch is only created to create a stable environment to create releases from. See the Release branch as the current stable release branch
  • All bug fixes are always applied to the /trunk/ which will be the continuous development branch (and which also holds all plugins).
  • Between feature freeze and release of first major/minor all bug fixes are applied to both /trunk/ and Patch branch.
  • Patch releases (third decimal number) only contain fixes selected on the basis of these criteria:
    • Security issues. Some risk is acceptable when implementing these. Urgency is important here.
    • A bug is very severe and can cause a lot of trouble for the users and admins. Some risk is acceptable when implementing these.
    • A bug is very common and annoying. Fix must be well tested for a while.
    • Bugfix where code inspection and experience tells us that this bug could become serious
    • A bug with a very simple fix with no practical risk.
    • Document changes that resolve issues that can have significant impact on some users. Doc updates are considered safe.
  • These kinds of changes will never be merged into the patch branch after a minor/major release and released in a patch release.
    • Complex bug fixes with many lines of code and/or many sources files and not being a security issue or very severe bug.
    • Changes to settings and preferences. Admins must be able to apply the package with the changed files without worrying that settings are reverted.
    • Any kind of enhancements or new feature.
    • Changes to plugins that are not in the standard release package.
  • If a bugfix cannot be merged from /trunk/ or to the patch branch because of conflicts, or an urgent security fix is needed, a special temporary fix may be applied to the patch branch instead.
  • Patch releases consist of a full release package and an archive with all the changed files since last major/minor release.

Release branching timeline

trunk
  |
  +------Release01x00 (branch)
  |           |
  |           |
  |           +-------Release01x00x00 (tag of major or minor release)
  |           |
  |           +-------Release01x00x01 (Tag)   Incl zip package is relative to 1.0.0
  |           |
  |           +-------Release01x00x02 (Tag)   Incl zip package is relative to 1.0.0
  |           |
  |           +-------Release01x00x03 (Tag)   Incl zip package is relative to 1.0.0
  |           |
  |          RIP (no longer used)
  |         
  |
  +------Release02x00 (branch)
  |           |
  |           |
  |           +-------Release02x00x00 (tag of major or minor release)
  |           |
  |           +-------Release02x00x01 (Tag)   Incl zip package is relative to 2.0.0
  |           |
  |           +-------Release02x00x02 (Tag)   Incl zip package is relative to 2.0.0
  |           |
  |           +-------Release02x00x03 (Tag)   Incl zip package is relative to 2.0.0
  |           |
  |          RIP (no longer used)
  |         
  
All we need now is a build script that will generate an archive with only the changed files relative to a given Subversion revision and we are ready to rock (begging)

Background for the process

During the life cycle of TWiki 4.0.X, we successfully released a number of hotfix releases which have been to the benefit of both users that got the urgent fixes, and the developers who could focus on the next release. On the other hand the hotfix scheme has added a 4th level to the release numbers. And the hotfixes were managed outside Subversion. We decided to change the process so that all fixes are handled in Subversion.

During the release of 4.2.0 we decided to feature freeze with one feature still in progress of being developed. This feature turned out more tricky and time consuming than expected causing the feature freeze to last for 3 months making it near impossible for developers not to break the feature freeze.

It was therefore decided that the Patch branch is created soon after the time of feature freeze and that the first minor/major release is created from the Patch branch. This should shorte (no longer used)n the feature freeze period on /trunk/ to a few days.

It is still the policy that the Patch branch is discontinued when the next minor/major is released and a new Patch branch is created. The community is too small to maintain and stable and a develop branch in parallel.

Ultrashort Tutorial

Branches and tags are created using svn copy

create the release branch from which releases are built

svn copy http:// svn.foswiki.org/trunk  http://svn.foswiki.org/branches/Release01x00 -m "Item90210: Creating a release branch for Release01x00"

Merge in fix from trunk

We assume that you have a checked out version of the current Patch branch so you can test the merged fix before committing it to Subversion.

In Subversion revision 7766 we have made an important update that fixes Item90210 which we want to merge to the current Patch branch.

Current working directory is the local checkout copy of the release branch

svn merge -r 7765:7766 http://svn.foswiki.org/trunk

Commit the changes

Put the Item90210 temporarily back into Actioning state if it has been closed or waiting for release.

svn commit -m "Item90210: Important hotfix of bug xyz merged to Release01x00 branch"

create the release tag after a release has been built and released

svn copy http://svn.foswiki.org/branches/Release01x00  http://svn.foswiki.org/tags/Release01x00x00 -m "Item90210: Creating a release tag for Release01x00x00"
then copy the files from the created zip into a checkout, and commit (used to build the next lot of topics)

Build the patch release

cd ../tools
perl build.pl release

Create the diff (for getting the list of changed files)

svn diff http://svn.foswiki.org/tags/Release01x01x00 http://svn.foswiki.org/branches/Patch01x01x01 > Release01x01x01.diff

Create the zip and tgz of all the changed files

We need a scripted solution to this

Discusions

@Creating a release tag adfter a release has been built and released

Shouldn't the tag be created in advance to make sure no commit to the trunk is disturbing the release build? -- MartinRaabe - 08 Feb 2009
Topic revision: r6 - 08 Feb 2009, MartinRaabe
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy