Difference between revisions of "Viewer Integration and Release Processes"

From Second Life Wiki
Jump to navigation Jump to search
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Warning|We are in the process of transitioning to the process described here.  For details, contact {{User|Oz_Linden}}
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.
}}
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.
<br clear="all"/>
<br clear="all"/>
{{Project Snowstorm Nav}}
{{Project Snowstorm Nav}}
Line 9: Line 7:
== The Process ==
== The Process ==


All projects begin by forking the [[#Repo-viewer-release|<tt>viewer-release</tt>]] 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).
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.


Viewer development proceeds with each project working from the same base and progressing through up to four phases:
Viewer development proceeds with each project working from the same base and progressing through up to four phases:
Line 17: Line 15:
# [[#Release|Release]]
# [[#Release|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).
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.
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.
Line 23: Line 21:
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 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 <tt>viewer-release</tt> 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.
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.


[[Image:Viewer-Repo-Flow-8.png|Project Integration, Beta, and Release]]
[[Image:Viewer-Repo-Flow-8.png|Project Integration, Beta, and 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.
The sections below detail the specifics of each phase.


===Project Integration===
===Project Integration===


# When a project is begun, the project leader or integration engineer:
# When a project is begun, the project leader or integration engineer:
#*Creates a project integration repository by forking the [[#Repo-viewer-release|<tt>viewer-release</tt>]] repository.
#*Creates a project branch in the [[#Repo-viewer|<tt>viewer</tt>]] 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.
#:(projects that are not yet ready to be published publicly use a branch in a Linden-private fork)
# Individual developers on the project fork working repositories from the project integration repository, and build [[#Channel-Test|Test]] viewers for their contributions to the project prior to integration.
# 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 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:
#: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]]
#::[[Image:Viewer-Icon-Developer.png]] [[Image:Viewer-Menu-Test-2.png]]
# 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).
# 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 TeamCity that builds the integration repository for QA, and may be made available to users as appropriate.
# 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:
#: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]]
#::[[Image:Viewer-Icon-Project.png]] [[Image:Viewer-Menu-Project-2.png]]
Line 46: Line 44:
===Beta Test===
===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 <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:
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]]
:[[Image:Viewer-Icon-Beta.png]] [[Image:Viewer-Menu-Beta-1.png]]


Line 54: Line 53:
:[[Image:Viewer-Icon-Release.png]] [[Image:Viewer-Menu-Release-1.png]]
:[[Image:Viewer-Icon-Release.png]] [[Image:Viewer-Menu-Release-1.png]]


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


There may be more than one Release Candidate at the same time.
It is normally the case that more than one project has a Release Candidate available.


===Release===
===Release===
Line 62: Line 61:
When it is determined that a particular Release Candidate is ready, it is promoted to the default Release viewer.
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 <tt>viewer-release</tt>, 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 out those changes.
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.


== Mercurial Repositories ==
== Repositories ==


;<span id="Repo-viewer-release"><tt>viewer-release</tt></span>
;<span id="Repo-viewer"><tt>viewer</tt></span>
:<tt>http://bitbucket.org/lindenlab/viewer-release</tt>
:<tt>https://github.com/secondlife/viewer</tt>
:The viewer-release repo records the code used to produce all released viewers through the latest Release version currently in production.   
: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 this repository is closely controlled.''
:''Write access to the <tt>master</tt> branch is closely controlled.''
:'''This is the stable repository that serves as the base for all development.'''
:'''This is the stable repository and branch that serves as the base for all development.'''


{{Note|The <tt>viewer-beta</tt> and <tt>viewer-development</tt> repositories used in earlier versions of this process are no longer used; <tt>viewer-release</tt> is the single canonical repository.}}
{{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 links to the project viewers repositories can be found on the [[Linden_Lab_Official:Viewer_Source_Repositories]]
;<tt>project, beta, and candidate viewer branches</tt>
:The links to the branches for projects in development can be found on the [[Linden_Lab_Official:Viewer_Source_Repositories]] page.

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.


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:

  1. Project Integration
  2. Beta Test (optional)
  3. Release Candidate
  4. 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.

Project Integration, Beta, and Release

The sections below detail the specifics of each phase.

Project Integration

  1. 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)
  2. 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:
    Viewer-Icon-Developer.png Viewer-Menu-Test-2.png
  3. 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).
  4. 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:
    Viewer-Icon-Project.png Viewer-Menu-Project-2.png

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:

Viewer-Icon-Beta.png Viewer-Menu-Beta-1.png

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:

Viewer-Icon-Release.png Viewer-Menu-Release-1.png

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.