Viewer Integration and Release Processes

Warning!

We are in the process of transitioning to the process described here. For details, contact Oz_Linden

This page describes how Viewer development projects are organized, including the Mercurial (hg) 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 forking the viewer-release repository, which 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).

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 (normally, 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 repository is then pulled to the viewer-release repository, the version number in that repository is incremented, and all other Release Candidate projects must merge those changes into their own projects and produce new Candidate versions to continue testing and be considered for promotion to Release.

The sections below detail the specifics of each phase, and the operations in Jira, the repositories, and the Viewer Version Manager associated with each.

Project Integration

When a project is begun, the project leader or integration engineer:
- Creates a project integration repository by forking the viewer-release repository.
This is a shared repository, normally under the bitbucket.org/lindenlab account, and may be either public or private according to the needs of the project.
Individual developers on the project fork working repositories from the project integration repository, and build Test viewers for their contributions to the project prior to integration.
Individual developer 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 repository (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 TeamCity that builds the integration repository 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. 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 small 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.

There may be more than one Release Candidate at the same time.

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 viewer-release, 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 out those changes.

Mercurial Repositories

viewer-release: http://bitbucket.org/lindenlab/viewer-release; The viewer-release repo records the code used to produce all released viewers through the latest Release version currently in production.; Write access to the this repository is closely controlled.; This is the stable repository that serves as the base for all development.

NOTE: The viewer-beta and viewer-development repositories used in earlier versions of this process are no longer used; viewer-release is the single canonical repository.