Development Branches
The LabKey source files are stored in multiple GitHub repositories.
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.
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.
The general release branch naming convention used is
release21.3-SNAPSHOT, in this case indicating the Mar 2021 release. A SNAPSHOT branch accumulates changes intended for the next upcoming maintenance release (which might be the first release of a given sequence, like 21.3.0, or a follow-on maintenance release like 21.3.5).
In addition to the standard feature branch pull request merging rules (development complete, tests complete, tests passing, PR code review, etc.), every PR merge to the release branch of a shared module (i.e., module that's part of a standard distribution, such as community, starter, professional, enterprise) has one additional requirement:
- An entry in the issue tracker. Please add the pull request link to the issue and the issue link to the PR description. You'll generally assign the issue to the person fixing it; assign to triage if there is a question about whether the issue should be fixed for the current release.
When it is time to publish a new maintenance release, approximately every two weeks, we merge the changes that have accumulated in the SNAPSHOT branch into the official release branch (
release21.3, for example). We tag the release branch with the number of the maintenance release, like 21.3.0 or 21.3.5. We may accelerate a maintenance release if there are critical fixes to deliver, such as security patches or fixes for work-stopping customer issues.
Merges
We periodically perform automated bulk merges from the active release branches back into
develop. Individual developers should NOT merge commits from the active release branches. However, if you make changes in an older release branch that need to be merged forward, you are responsible for requesting it.
Related Topics
