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

• How To Propose A Viewer Feature
• How To Submit A Viewer Change
• Integration & Release Processes
• Feedback Portal
• Github

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

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

1. Developers fork from the viewer-development repository to create project integration and working repositories
2. 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.

See How To Submit A Viewer Change.

Integration Phase

1. 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
2. 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).

Beta Phase

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

1. The tag "version-betaN" is added to the current tip of the viewer-development repository, and those changes are pushed to the viewer-beta repository.
2. The viewer patch version number in indra/llcommon/llversionviewer.h is incremented (so that Development versions have higher numbers than beta viewers)
3. QA does a full regression test of the resulting Beta build, including tests of all new changes.
   • If it passes QA, the build is released on the beta channel, if not repairs will be committed to viewer-beta (and pulled back to viewer-development), a new candidate will be built (with N having been incremented).

Release Phase

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

1. A version-release tag is added to the tip of the viewer-beta repository
2. The contents of the viewer-beta are pushed to viewer-release, which triggers the release candidate build
3. 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)
4. The release channel is updated to the new release viewer
5. 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.

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 (or being built for) the Beta channel.

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.

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-development. 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:

1. 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.

2. 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).

3. Any changes to strings in the user interface must have been reviewed by the documentation team.
4. 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).

5. 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.

6. 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.