Difference between revisions of "Viewer Integration and Release Processes"

Latest revision as of 01:14, 27 January 2024

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.

@@ Line 1: / Line 1: @@
+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.
+<br clear="all"/>
 {{Project Snowstorm Nav}}
 __TOC__
 <br clear="all"/>
-==Overview ==
+== The Process ==
-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.
-The ultimate arbiter of these processes is the '''Viewer Product Team''', which is composed of the product managers from Linden Lab groups that are engaged in viewer development.  The Viewer Product Team is chaired by the Product Manager of the [[Snowstorm Team]].
-There are three core hg repositories (each repository is in effect a branch; the processes described here do not rely on using the hg branching features within a repository):
-* [[#Development|Development]] is the integration trunk
-* [[#Beta|Beta]] is used to test and stabilize releases and build beta releases
-* [[#Release|Release]] is used to build official stable releases
-all three of these repositories are used by both Linden Lab development teams and open source developers; they are accessible at hg.secondlife.com, but only the specific Linden team responsible for each one has commit access to it.  Detailed descriptions of each, and the processes for moving changes between them, are below.
-===Development===
-[[Image:Development.png|right|caption="Project and Development repositories/branches"]]
-'''Location:''' [http://hg.secondlife.com/viewer-development http://hg.secondlife.com/viewer-development]
-:'''This is the conceptual ‘trunk’ from which all development, both inside and outside Linden Lab, should be derived.'''
-It is built continuously, with the resulting viewers being publicly available. There are official builds from this repository posted approximately bi-weekly on the “Second Life Development Viewer” channel for the brave or curious, and nightly builds (location TBD) for the really adventurous.
-Ordinary development, whether for feature development or bug fixes, pulls from this repository to a [[#Project|Project]] repository, and tracks all changes made in Development as work is done in that Project repository. Code is pulled back to this repository for integration (see [[#Development Integration Criteria|Development Integration Criteria]] below).
-Ideally, any bi-weekly official build from this repository is a candidate for the creation of a new official viewer release.
-===Project===
+All projects begin by creating a branch in the [[#Repo-viewer|<tt>viewer</tt>]] git repository, the <tt>master</tt> 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.
-'''Location:''' ''determined by the development team, but somewhere at hg.secondlife.com is encouraged''
+Viewer development proceeds with each project working from the same base and progressing through up to four phases:
+# [[#Project_Integration|Project Integration]]
+# [[#Beta_Test|Beta Test]] (optional)
+# [[#Release_Candidate|Release Candidate]]
+# [[#Release|Release]]
-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 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 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).
-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).
+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.
-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.
+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 development is complete, or reaches an appropriate milestone, changes from a Project repository are pulled back to the Development repository by the Snowstorm Team; see [[#Development Integration Criteria|Development Integration Criteria]] below.'''
+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 <tt>master</tt> 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.
-==Development Integration Criteria==
+[[Image:Viewer-Repo-Flow-8.png|Project Integration, Beta, and Release]]
-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:
+The sections below detail the specifics of each phase.
-# '''Functionality must have been reviewed and accepted by the Product Owner'''
+===Project Integration===
-#: 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.
-# '''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.
-#:* 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).
-# '''There must be a test plan'''
-#: The test plan must describe in detail how Integration QA can validate the modified behavior.
-# '''The Project repository must have merged in the latest changes from Development.'''
-#: 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 [http://www.ehow.com/about_5108486_karmic-debt.html karmic debt].''
-# '''There must be [http://secondlifegrid.net.s3.amazonaws.com/docs/SLVcontribution_agmt.pdf Contribution Agreement]s 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 requests that changes be integrated into the Development repository; see [[How To Submit A Viewer Change]].
+# When a project is begun, the project leader or integration engineer:
+#*Creates a project branch in the [[#Repo-viewer|<tt>viewer</tt>]] 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 [[#Channel-Test|Test]] viewers for their contributions to the project prior to integration.
+#:Individual developer builds and the early project builds are <span id="Channel-Test"><tt>Second Life Test</tt></span> viewers, distinguished by the Test icon and by the dark red color of the top menu background:
+#::[[Image:Viewer-Icon-Developer.png]] [[Image:Viewer-Menu-Test-2.png]]
+# 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 [[#Channel-Project|Project]] viewer build on Github for QA, and may be made available to users as appropriate.
+#:Project viewer builds use a distinct channel "<span id="Channel-Project"><tt>Second Life Project ''project-name''</tt></span>".  Using a Project channel causes those builds to use the Project Viewer icon and have a light blue top menu background:
+#::[[Image:Viewer-Icon-Project.png]] [[Image:Viewer-Menu-Project-2.png]]
-==Beta and Release==
+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|Beta Test]] phase and proceed to directly to producing a [[#Release_Candidate|Release Candidate]].
-When the Viewer Product Team decides that a Development build is a good candidate for creating a general release version, the changes for that build are moved from the Development repository through the [[#Beta Repository|Beta]] and [[#Release|Release]] repositories following the [[#Beta and Release Process|Beta and Release Process]].
+===Beta Test===
-[[Image:DevelopmentToRelease.png|right|caption="Development through Beta to Release"]]
+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 <span id="Channel-Beta"><tt>Second Life Beta ''project''</tt></span> channel.  Using a Beta channel causes the viewer to have the beta viewer icon, and a purple menu background:
+:[[Image:Viewer-Icon-Beta.png]] [[Image:Viewer-Menu-Beta-1.png]]
-===Beta Repository===
+===Release Candidate===
-'''Location:''' [http://hg.secondlife.com/viewer-beta http://hg.secondlife.com/viewer-beta]
+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 <tt>Second Life Release</tt> channel, so they use the default icon and menu color:
+:[[Image:Viewer-Icon-Release.png]] [[Image:Viewer-Menu-Release-1.png]]
-: The Integration and QA team pulls from Development into the Beta repository (since the Beta repository will contain only change sets that are already in Development, this pull does not require any merges).
+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.
-: Final QA and stabilization are done using builds from the Beta repository; builds from this repository selected by the Viewer Product Team are released on the “Second Life Beta Viewer” channel.
+It is normally the case that more than one project has a Release Candidate available.
-: Any bug fixes on this repository are immediately pulled to the Development repository by the Snowstorm Team.
+===Release===
-===Release Repository===
+When it is determined that a particular Release Candidate is ready, it is promoted to the default Release viewer.
-'''Location:''' [http://hg.secondlife.com/viewer-release http://hg.secondlife.com/viewer-release]
+Sources for that project are then pulled (not merged, since they are a
+direct descendant) to the <tt>master</tt> branch, a <tt>''major''.''minor''.''patch''-release</tt> tag is added, the patch (third level) version number in <tt>viewer-release</tt> is incremented, and then all other projects merge those changes.
-: When the Viewer Product Team decides that a Beta branch is ready for release, the Integration team pulls changes from Beta into the Release repository (this is the only path into the Release repository, so this does not require any merges), where it is tagged and built to produce the viewer released on the “Second Life Release” channel.
+== Repositories ==
-==Beta and Release Process==
+;<span id="Repo-viewer"><tt>viewer</tt></span>
+:<tt>https://github.com/secondlife/viewer</tt>
+:The <tt>viewer</tt> repository <tt>master</tt> branch is the source used to produce all released viewers through the latest Release version currently in production.
+:''Write access to the <tt>master</tt> branch is closely controlled.''
+:'''This is the stable repository and branch that serves as the base for all development.'''
-When the Viewer Product Team determines that one of the official “Development” builds appears to be ready (low crash rate, general acceptance by the community) it is  promoted to an official numbered Viewer release via the following process:
+{{Note|The <tt>viewer-release</tt>, <tt>viewer-beta</tt> and <tt>viewer-development</tt> repositories used in earlier versions of this process are no longer used.}}
-# The Snowstorm Team adds a release candidate tag to Development.
+;<tt>project, beta, and candidate viewer branches</tt>
-# The Release Manager
+:The links to the branches for projects in development can be found on the [[Linden_Lab_Official:Viewer_Source_Repositories]] page.
-## Pulls changes from the release candidate tag on Development to the Beta repository (this should not require any merge).
-## Builds branch on Beta
-## Creates a release document that includes test plan information and the list of all the changes included in the build (list of JIRAs, etc). Proper attention to detail during development should make this simple.
-## Offer build to QA for testing and evaluation
-# In QA, the integration test team:
-## Executes the set of test plans for all of the changes included
-## Performs a general smoke test on overall functionality
-## Identifies overall quality and level of risk for release
-# The Viewer Product Team evaluates quality, risk and feature set and decides whether or not to release the build as Beta. Options are:
-#* ''Fail'': this beta candidate is rejected and the process starts over at some different tag on Development (step 1).
-#* ''Fix First'': specific bugs / issues are identified that must be fixed before ship. These bugs are fixed in the Beta repository.
-#** Fixes made to the Beta repository are merged to Development by the Snowstorm Team as soon as they are found to be complete.
-#* ''Ship'': the Beta is ready as-is.
-# Once a build is approved for ship, the Release team does its magic to get the build into the field as a Beta build on the “Second Life Beta Viewer” channel.
-# Once a Beta is in the field, we watch for new bugs, crash rate, performance, and other data. If the Beta needs further iteration, we might iterate multiple times on the Beta branch (return to step 4).
-# Once the Viewer Product Team decides the Beta is of sufficient quality to ship as an official viewer, the Release team:
-## Tags the Beta branch
-## Pulls from the tag on Beta to Release
-## Tags and builds from the Release repository.
-## Releases on the “Second Life Viewer” channel.