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.

Merges

We periodically perform bulk merges from the release and alpha branches back into trunk/develop. Individual developers should NOT merge commits from release branches.