Source branches

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

http://svn.secondlife.com/trac/linden/browser/branches

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

• "maintenance" - bug fixes and small features that don't warrant their own branch get checked into maintenance. There are actually several maintenance branches internally, UI/Server/Viewer/Rendering. 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.
• feature branch a major new feature gets developed here before turning into various first looks (snapshots of this branch), or getting eventually merged into "release" and no longer maintained as a feature branch.
• "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 one of the "maintenance" branches for the small stuff, and only gets merged into release once QA has happened). Developers 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.
• Numbered branch (currently "Branch_1-18-3-Viewer") - this is a branch of release that is where RC snapshots come from, and where final releases are checked in. Small fixes can be checked in here if they fix regressions.

Linden Lab does feature development on temporary branches. As those features are validated by the QA group, they are merged into the "release" branch. 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.

Release Candidates

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.

The intended process is:

1. developers commit changes that have passed QA into the code trunk
2. at appropriate times we freeze (branch off) from the trunk to start stabilizing a version and call it an RC
3. we stabilize the RC branch via iterations of internal QA, fixes, public releases, fixes; meanwhile (1) continues unblocked
4. when deemed "good enough" then the RC is released.

We triage changes going into an RC. When the RC is first frozen, the bar is roughly: regression fixes, bug fix for new features, fit-and-finish on new features, internationalization/localization changes, security, performance, text-only UI changes. We try and raise the bar with each RC iteration.

The purpose is to get a "we think it's ready" version to the public for use on the service. Some times we're closer to being ready out of the gate than others. Apart from changes that meet the triage bar, the feature set should be frozen so that as an RC is iterated on the risk is constantly being reduced.

There are humans in the triage loop, and yes, we may say "you know what, that change is low risk and high impact, and we'd prefer to have it out in the RC and next release, and not wait another month for the next go-round of the cycle".

Basically, almost all development work happens in maintenance or feature branches. Those merge into the trunk (named "release", a source of potential confusion). Periodically an RC is branched off the trunk. So something can be marked "fixed internally" on JIRA when it's in a maintenance branch but, until it merges into the trunk it's not going to be in an RC.

This is best shown with a picture. It is of course overly simplified. The flow is left to right. This diagram *just* shows how a fix that goes in while 1.18.6 RCx is out may still not make it into 1.19.0 and is not a complete picture at all. The point marked 'fix foo submitted' is actually the point it will often get marked as 'fixed internally' or 'fix pending', and when it starts going through internal QA.

There are always exceptions. Some work is done right in the RC branch to fix regressions. Some work doesn't affect production code so can go right into the trunk. But the goal is to have nothing enter the trunk that hasn't passed QA.

We internally track this by tagging the items with an actual Fix Version only at the point where the change has merged into the trunk - which is the soonest point you can predict what version it will be in. We do this by tracking the maintenance and feature branches as they go in and doing bulk updates. Therefore, Status = Resolved, Resolution = Fixed, Fix Version = 1.19.0 indicates that not only is it fixed but it's merged into the trunk. We'd create a Version 1.19.1 as soon as 1.19.0 is frozen (branched) so that the next fixes to merge into the trunk can be marked appropriately.

Ideally we would sweep through the JIRAs that have PJIRA counterparts and do the same thing. We're still trying to get tools/processes into place for this, and additional people to help. There's also the overhead that suddenly 1.19.1 appears in PJIRA before we're even ready to really start talking in detail about 1.19.0, so suddenly a gazillion questions come our way. But that's why this is fun.

Maintenance

"Maintenance" is now subdivided into four branches in order to distribute and organize maintenance responsibilities between development teams. (new as of August 2007)

Maintenance Branches

• maint-ui
  • UI specific maintenance tasks
• maint-render
  • Render specific maintenance tasks
• maint-viewer
  • Other viewer only maintenance tasks
  • e.g. viewer crashes, audio, misc
• maintenance
  • Tasks that involve server-side changes
  • Tasks that affect shared viewer / server libraries
  • Tasks that in any way affect messaging