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.
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
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.
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.
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.