We create SVN branches for all of our official releases. This is the code used to build the installers that we post for all users. As such, we have a strict set of rules for what changes are allowed. The branches follow the general naming convention of "https://hedgehog.fhcrc.org/tor/stedi/branches/release13.2". They are created at the end of the final sprint of a given release. All check ins made to the release branch require:
- An entry in the issue tracker.
- Approval from a member of the Triage committee.
- A code review from another developer.
- In the checkin description, reference the issue and say who did the code review.
Many of our customers want us to deliver new functionality more often than we do a general release. However, they still require that the core server remain stable. As such, we create a separate "modules" branch for each release. Checkins for a customer-specific module are allowed without a code review or triage approval. Note that no changes to the core server code are permitted, however. These branches use the naming convention of "https://hedgehog.fhcrc.org/tor/stedi/branches/modules13.2".
We also create separate branches for each sprint (currently aligned with calendar months). Like release branches, changes to the sprint 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 sprint branch.
We periodically do bulk merges from the release branch into the modules branch, and from the modules branch to the trunk. We also merge sprint 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 a sprint branch from multiple sprints ago (e.g., a change in sprint branch 1, when it is now sprint 3) are typically only merged into trunk. In the example given, the change to sprint branch 1 would only go to trunk, and not be merged into sprint branch 2, unless we intend to also rerelease sprint branch 2 to a customer.