Viewer Integration and Release Processes

This page describes how Viewer development projects are organized, including the git repositories, builds, and the integration and release processes through which changes move to get from the developer (either inside or outside Linden Lab) to the Second Life Viewer.

Open Source Quick Links

The Process

All projects begin by creating a branch in the viewer git repository, the master branch in this repository contains the sources used to build the current default Release viewer (with the third level version number incremented by one so that any new development versions are higher numbers). Normally, Linden development project branch names begin with project/* and a project name, optionally followed by an underscore and some more mnemonic label.

Viewer development proceeds with each project working from the same base and progressing through up to four phases:

Project Integration
Beta Test (optional)
Release Candidate
Release

There may be any number of projects that simultaneously have either a Project, Beta, or Release Candidate viewer available (any given project will have only one viewer available in one of those forms).

The Viewer Version Manager is a central service that manages notifying viewers in each channel when a newer version is available. In Project and Beta channels, normally only one version will be available at any given time; when a new version is released by the project team, all earlier versions are invalidated so that upgrading to the newest version is mandatory.

When the project team is ready to evaluate a Release Candidate version, a cohort is defined in the Release channel. The Viewer Version Manager randomly selects a limited number of users and offers optional upgrades to the Release Candidate version to users in the cohort. The project team and product management evaluate the experience of users in the cohort by monitoring bugs reported against that version, its crash and frame rates, and any other appropriate metrics.

When a Release Candidate is found to be of sufficiently high quality, it is promoted to Release status and becomes the default Release viewer. The source from its project branch is then pulled to the master branch, the version number in that branch is incremented, and all other Release Candidate projects must merge those changes into their own branches and produce new Candidate versions to continue testing and be considered for promotion.

The sections below detail the specifics of each phase.

Project Integration

When a project is begun, the project leader or integration engineer:
- Creates a project branch in the viewer repository.
(projects that are not yet ready to be published publicly use a branch in a Linden-private fork)
Individual developers may create personal branches off the project branch for work that is not ready to integrate, and build Test viewers for their contributions to the project prior to integration.
Individual developer builds and the early project builds are Second Life Test viewers, distinguished by the Test icon and by the dark red color of the top menu background:
When individual work is ready, it is merged into the project integration branch (whether this merge is a push by individual developers or managed as a pull request to the project integration engineer is up to the project team).
The project integration engineer maintains a canonical Project viewer build on Github for QA, and may be made available to users as appropriate.
Project viewer builds use a distinct channel "Second Life Project project-name". Using a Project channel causes those builds to use the Project Viewer icon and have a light blue top menu background:

The project may decide to produce a beta release in order to do higher-risk testing and/or to get wider user testing, or it may elect to skip the Beta Test phase and proceed to directly to producing a Release Candidate.

Beta Test

Whether or not a project releases a Beta viewer is up to the project (in recent times this has been unusual). If the project elects to release a beta, it is built for and released on the Second Life Beta project channel. Using a Beta channel causes the viewer to have the beta viewer icon, and a purple menu background:

Release Candidate

When the Viewer Release Product Owner and project lead determine that the project has met its functional goals and it is believed to be ready for general release, the Release Candidate phase begins. Release Candidate builds use the Second Life Release channel, so they use the default icon and menu color:

Release Candidates are offered as optional updates to a randomly selected subset of users running a Release viewer. The project team and QA monitor the bugs reported against the Release Candidate, any crash reports it uploads, and the performance statistics for it to determine whether or not it is ready to be promoted to the default Release viewer.

It is normally the case that more than one project has a Release Candidate available.

Release

When it is determined that a particular Release Candidate is ready, it is promoted to the default Release viewer.

Sources for that project are then pulled (not merged, since they are a direct descendant) to the master branch, a major.minor.patch-release tag is added, the patch (third level) version number in viewer-release is incremented, and then all other projects merge those changes.

Repositories

viewer: https://github.com/secondlife/viewer; The viewer repository master branch is the source used to produce all released viewers through the latest Release version currently in production.; Write access to the master branch is closely controlled.; This is the stable repository and branch that serves as the base for all development.

NOTE: The viewer-release, viewer-beta and viewer-development repositories used in earlier versions of this process are no longer used.

project, beta, and candidate viewer branches: The links to the branches for projects in development can be found on the Linden_Lab_Official:Viewer_Source_Repositories page.