Viewer Integration and Release Processes

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

There are three core hg repositories. Each repository is in effect a branch; the processes described here do not rely on using the hg named branches within a repository (use of named branches is discouraged):

viewer-development: is the integration working repository
viewer-beta: records the sources in the current beta release, and may be used to repair problems in it
viewer-release: records the sources in the current stable release

The viewer-release repository is the stable viewer source; this is the base from which developers should pull to working repositories.

All three of these repositories are used by both Linden Lab development teams and open source developers; they are accessible at hg.secondlife.com. Detailed descriptions of each, and the processes for moving changes between them, are below.

Phases

Development Phase

Developers fork from the viewer-release repository to create project integration and working repositories
Each project/team normally has a shared repository (which may be either public or private, according to the needs of the project) into which developers push work ready for team-level QA.
- Project viewers are built from this branch and made available to users as appropriate.

Note that the stable viewer source is the viewer-release repository: changes that are in any of the repositories that feed into that stable repository may be substantially changed or completely discarded.

See How To Submit A Viewer Change.

Integration Phase

When team QA has passed, and the Development Integration Criteria are met, the team (Snowstorm, for open source contributions) leader requests that the changes from the project repository be merged
After review and approval, the changes are pulled into the viewer-development repository (a fork of viewer-release).
- Commits to the viewer-development repository trigger builds of Development viewers; these are available from the public wiki (but do not have a Version Manager update channel).

Note: if severe problems are detected in the builds from the viewer-development repository, and a timely repair is not found, the repository will be renamed and kept only as needed for the problem resolution. A new viewer-development repository will be created by forking from viewer-release; because of this, pulling from viewer-development is not normally appropriate.

Beta Phase

When Linden Lab determines that the changes in viewer-development should be built as a beta candidate, one is created:

The tags "viewer-beta-candidate", "version-start", and one for the DRTVWR issue id (used for tracking within the Lab).
QA does a full regression test of the resulting Beta build, including tests of all new changes.
- If problems are found by QA, and the solution is non-trivial, the viewer-development repository is renamed to be kept for as long as needed for problem diagnosis; all the merge requests are returned to the development teams as Failed, and a new viewer-development repository is created by forking viewer-release.
- If it passes QA:
1. The "version-beta#" tag is added, and the changesets are pushed to the viewer-beta repository

Note: because the viewer-beta repository may be re-created by forking from viewer-release, pulling from it is not appropriate except for working on a problem specific to the beta build.

Release Phase

When Linden Lab decides that the Beta results are acceptable, the release build is begun:

The "viewer-release-candidate" tag in the viewer-beta repository is moved to trigger the release candidate build
QA does a regression test on the release candidate viewer (aside from the channel, build version number, and build date, it should be identical to the most recent beta)
The tags are added for the version number "version-release", and one for the DRTVWR issue identifier, and those changes are pushed to the viewer-release repository
The release channel is updated to the new release viewer
Developers pull and merge all changes from viewer-release back to project and working repositories

Repositories

Canonical Integration and Release Repositories

viewer-release: This is the primary stable code repository; all normal development should be based on this repository.; http://hg.secondlife.com/viewer-release; The viewer-release repo records the code used to produce all released viewers through the latest Release version currently in production.; In extraordinary circumstances, fixes for especially urgent bugs may be committed directly to this repository without first going through the normal development and beta repositories below; any such changes are immediately pulled to the Development and Beta repositories.

viewer-beta: http://hg.secondlife.com/viewer-beta; The viewer-beta repo is a snapshot recording the sources for the viewer currently in the Beta channel.; Changes in this repository may not be accepted, or may be substantially changed; pulling from this repository is not recommended.; If severe bugs are found in a beta build, fixes may be committed directly to this repository without first going through the normal viewer-development repository below; any such changes are immediately pulled back to viewer-development.

viewer-development: http://hg.secondlife.com/viewer-development; This repo is the integration working repository; it is built continuously, with the resulting viewers being publicly available from Downloading test builds and the Snowstorm Team page. Submissions from development projects are merged here.; Changes in this repository may not be accepted, or may be substantially changed; pulling from this repository is not recommended.; When Linden Lab decides that a given Development build is a good candidate for release as a Beta, the tag "<next version>-start" and "viewer-beta-candidate" (this tag moves for each beta candidate build) are applied to this repository and the beta candidate built from those tags.

Project Repositories

Project repositories may be built as needed by the developers; viewers produced from Project repositories may be made available for public testing at times chosen by the development team.

Any development, whether a single engineer fixing a minor bug or a large team building a major feature, is done in a Project repository that pulls from viewer-release. Large projects will likely have individual repositories pulling from and pushing to their team Project repository; how this is managed and tracks changes made to Development is under the control of the developer(s) on the project.

There may be any number of other repositories created by project teams or developers either inside or outside Linden Lab; these are Project repositories. The default channel identifier built from these repositories is "Second Life Developer". Projects that plan to make test viewers publicly available, which is encouraged, should change this to a project-specific value in those viewers.

Linden development teams releasing a Project Viewer should use the (internal) Project Viewer Release Checklist.

Development Integration Criteria

In order to be eligible to be pulled into the Development repository, the changes in a Project repository must satisfy all of the following criteria:

Functionality must have been reviewed and accepted by the Product Owner
Review is based on the requirements/user stories defined at the beginning of a sprint, and then at the end of a sprint during Acceptance Testing. For Linden development teams, these checks are the normal sprint reviews, not an additional step. For open source developers, the Snowstorm Team will coordinate these reviews with the appropriate Linden reviewers.

Whenever possible, any substantial change in functionality or high risk change should have been released as a Project Viewer or otherwise made available for testing by residents on the main grid prior to integration.
Design and code must have been reviewed by competent reviewers.
In this context, “competent” means appropriate subject matter experts for the code that is modified. Linden development teams determine for themselves who the competent reviewers are; for open source contributions, the Snowstorm Team will determine the appropriate reviews. We have a public Code Review Tool for this purpose.
- If there are changes to code or protocols shared between the viewer and the simulator, those changes must include unit tests that at minimum validate that the behavior before and after the change is compatible. If that is not possible due to the nature of the change, then the change must include documentation on how the interfaces are changed, and the relevant simulator developers must review and approve them (for open source contributions, the Snowstorm Team will coordinate and facilitate these reviews).
Any changes to strings in the user interface must have been reviewed by the documentation team.
Any critical user interface changes must have been localized.
Critical changes are ones that could lead to serious user errors if they were unable to read the strings. See the Viewer Localization instructions (internal) for specifics on how to get translations produced as a part of your development (open source contributors will do this through the Snowstorm Team).
There must be a test plan
The test plan must describe in detail how the modified behavior can be validated and tested. We provide a handy test plan template to help make this trouble free.
The Project repository must have merged in the latest changes from Development.
In this context, "latest" means certainly within a week, and better if it is within a couple of working days.

The results must be validated by building viewers for all platforms and doing at least minimal viewer testing. Breaking the Development build is considered bad practice and may incur karmic debt.
- There must be Contribution Agreements on file from all contributors to the change if the Project repository contains changes made by non-Lindens.

When these criteria have been met, the development team may integrate into the Development repository; see How To Submit A Viewer Change.