Development Branches

The LabKey source files are stored in two version control systems: (1) the build system and test sample data are stored in a Subversion (SVN) repository and (2) the core platform and all commonly distributed modules are stored in multiple GitHub repositories.

The vast majority of development takes place on the GitHub repositories using our standard feature branch workflow. After review and test verification, feature branches are typically merged to the develop branch of each repository, making develop a reasonably stable development branch. Any commits to the SVN repository are made directly to trunk, with no feature branch workflow involved.

Release Branches

We create version control branches for all official releases. This is the code used to build the distributions that we post for clients and the community. As such, we have a strict set of rules for what changes are allowed. Release branches are created around the first working day of a month in which we plan to release.

A Subversion release branch uses the general naming convention branches/release19.2-SNAPSHOT and accumulates changes intended for the next upcoming patch release (which might be the first release of a given sequence, like 19.2.0, or a follow-on patch release like 19.2.5).

Git-based repositories use a similar pattern, with snapshot branches named release19.2-SNAPSHOT or similar.

All changes committed to Subversion or Git branches for shared modules require:

• An entry in the issue tracker.
• Approval from a member of the Triage committee.
• A code review from another developer (performed through a pull request for Git repos).
• A checkin description which references the issue number and specifies who performed the code review.

When it is time to publish a new patch release, approximately every two weeks, we merge the changes that have accumulated in the SNAPSHOT branch into the official release branch (release19.2, for example). We tag the release branch with the number of the patch release, like 19.2.0 or 19.2.5. We may accelerate a patch release if there are critical fixes to deliver, such as security patches or fixes for work-stopping customer issues.

Alpha Branches

During non-release months, we create new branches and tags to mark that month's alpha release. Alpha branches follow the naming convention branches/alpha_19.2_1 for SVN. In Git repositories, we tag alpha releases similarly alpha_19.2_1 and use the master branch to represent the most recent alpha release. alpha_19.2_1 is the first alpha release of what will become version 19.2.0. We rarely make changes to alpha branches, but any change requires an entry in the issue tracker, triage approval, and a code review.

Merges

We periodically perform bulk merges from the release and alpha branches back into trunk/develop. Individual developers should NOT merge commits from release or alpha branches; 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 develop code has already changed, or you make a better but riskier fix in develop), please alert the developer handling the merge duties and give guidance.