Release Branches

We create version control branches for all of our official releases. This is the code used to build the distributions that we post for all users. As such, we have a strict set of rules for what changes are allowed.

Subversion-based code uses the general naming convention of "https://svn.mgt.labkey.host/stedi/branches/release19.1" and is used as the source of the official releases. This branch is created around the first day of the month in which we will release.

We also create a snapshot version of the branch, named following a pattern like "https://svn.mgt.labkey.host/stedi/branches/release19.1-SNAPSHOT". Changes are committed to this branch, and all check-ins made require:

  • An entry in the issue tracker.
  • Approval from a member of the Triage committee.
  • A code review from another developer.
  • A checkin description which references the issue number and says who did the code review.
Git-based repositories use branch names like "release19.1-SNAPSHOT" and "release19.1".

Approximately every two weeks when it is time to publish a new patch release, we will merge the changes that have been accumulated in the snapshot branch into the official release branch. We tag the release branch with the number of the patch release, like 19.1.0 or 19.1.5. We will also accelerate patch releases if there are critical fixes to deliver, such as security patches or fixes for work-stopping customer issues.

Alpha Branches

We also create separate branches around the first of non-release months, representing an alpha release. Like release branches, changes to the alpha branch require an entry in the issue tracker, triage approval, and a code review. We typically make a very small number of changes in the alpha branch. Alpha branches follow the naming convention "https://svn.mgt.labkey.host/stedi/branches/alpha_19.2_1" which is the first alpha release of what will become version 19.2.0.

Merges

We periodically do bulk merges from the release branch into the trunk. We also merge alpha branch changes into the trunk. Individual developers should NOT merge their checkins. This is currently a rotating responsibility, assigned to a developer for a period of time.

If you make a branch checkin that you expect to be difficult to merge (for example, you know that the trunk code has already changed, or you make a better but riskier fix in the trunk), please alert the developer handling the merge duties and give guidance.

Changes in an alpha branch from multiple sprints ago (e.g., a change in alpha branch 1, when it is now alpha 3) are typically only merged into trunk. In the example given, the change to alpha branch 1 would only go to trunk, and not be merged into alpha branch 2, unless we intend to also rerelease alpha branch 2 to a customer.

Discussion

Was this content helpful?

Log in or register an account to provide feedback


previousnext
 
expand all collapse all