Linden Lab Repository Strategy

This is to document Linden Lab's branching strategy, with respect to its open development as well as its private development. Please see annotations below the image.

Note from Q: as of 21 March 2010 we haven't yet implemented all of this -- some of it is waiting for the final release of Viewer 2.]

A) The "viewer-public" branch is a Linden-internal branch stored in the Mercurial (hg) source control system. It is the upstream (main, topmost) branch for all viewer development at LL. Much of, but not all, viewer development will take place on this branch.

B) The internal viewer-public branch contains some code that cannot be made public. In particular, certain third-party libraries like Kakadu and the Vivox voice library are not exportable. We run a script that automatically excludes these libraries and packages the branch up, and exports it to a Subversion repository called viewer-external.

C) The open source Snowglobe project maintains its own repository. Its upstream repository will be viewer-external. On a frequent basis, it will import changes from viewer-external and incorporate them.

D) Linden Lab maintains an internal branch called viewer-private, which frequently and routinely pulls from viewer-public. It normally contains everything in viewer-public, plus whatever private work Linden does.

E) A Linden software developer creates feature F1 in the viewer-public branch. (Note that in this chart, features appear on each branch when they are first imported to that branch.) F1 will routinely and automatically be exported to viewer-external, and will as a matter of course also appear in Snowglobe.

F) Meanwhile, feature F2 is being developed internally to Linden Lab and not being made public for the time being. It only appears on the viewer-private branch.

G) Routine pull from viewer-public imports F1 into viewer-private.

H) Feature F3 is created by a Snowglobe contributor.

I) Linden Lab decides that it wants to import F3, so it is pulled into viewer-public. Routine export causes it to land in viewer-external shortly thereafter.

J) Linden plans to release a new viewer, so it explicitly pulls all changes in from viewer-public.

K) Linden then clones viewer-private to make viewer-release. Stabilization and beta are based around the viewer-release branch. (The internal branching strategy is more complex than this, but not necessary for this discussion.)

L) Meanwhile, internal development for a future release can continue on viewer-private. Feature F4 will not be made public until a later release.

M) Once the viewer is ready to release (normally in public beta), viewer-release is merged back into viewer-public, including the private feature F2. F2 then makes its way into viewer-external and Snowglobe

N) The viewer-release branch is released and no further development takes place on that branch until the next release cycle.

O) A Snowglobe feature that Linden Lab doesn't choose to take lives only on the Snowglobe branch.