Source branches

The public version control repository provided by Linden Lab has many of the same branches that Linden Lab's internal repository has.

There are generally four major branches at all times, along with many temporary development branches:

• Numbered branch (currently "Branch_1-18-0") - this is where the current release resides, and where very minor fixes get checked in for the next minor release (e.g., if 1.15.0.2 is the last release, then changes for 1.15.0.3 would get checked in here).
• "release" - the main trunk of development. This is often referred to as "head" or "trunk" in other organizations. Linden Lab is rather conservative about what gets checked into release, though, preferring that development work mainly happens on branches (either a dedicated feature branch, or "maintenance" for the small stuff, and only gets merged into release once QA has happened. We aspire to keep release compatible with the agni (main) grid. All branches occasionally pick up changes from release, and are occasionally merged back into release.
• DEPRECATED: "release-candidate" - when Linden Lab is working toward a major release, this branch provides a similar function to release, but is for changes that are compatible with the beta grid (usually aditi) rather than the release grid. Following the release of 1.18, this branch has been deprecated. Incompatible changes go directly into numbered branches.
• "maintenance" - bug fixes and small features that don't warrant their own branch get checked into maintenance. Changes from maintenance are periodically merged up to release after QA has tested a build from the branch. Many source code contributions from the community land in this branch first.

Other branches are typically branched from release.

Linden Lab does feature development on temporary branches. As those features are validated by the QA group, they are merged into the "release" branch. Periodically, the beta grid is refreshed with the latest code, which represents a combination of the latest client and server code (which are currently in a unified codebase within Linden Lab). Three kinds of releases are possible:

• Server-only - may occur with or without downtime
• Viewer-only - optional viewers
• Viewer and Server (with dependencies) - required viewer updates. This case is avoided whenever possible.

When a release is about to happen, a release candidate (RC) branch is created for work on that release (e.g. "Branch_1-13-2"). In the rare case of a client/server update with dependencies, pending changes which would break compatibility with the main grid and require downtime and new viewers for an update are merged into this release candidate branch.

Following this point, only stability work is done on the branch - developers fix any new bugs above a certain priority that are found by QA.

For server-side changes, the beta grid is updated frequently as the stabilization occurs. Once the code is finalized, it is deployed to the main grid. After that, any stability work in the RC branch gets merged back into "release", and the process repeats for the next major release. Additional patches may be made to the RC branch and deployed to the grid.

For viewer-side changes, once the code is deemed stable it is released as Release Candidate viewer. Any bug reports which are new to this version are triaged. As fixes are made, additional RC viewer builds may be made and released. Once no more bugs have passed triage, the final RC becomes the next released viewer.