Difference between revisions of "Viewer Integration and Release Processes"

From Second Life Wiki
Jump to navigation Jump to search
m
m
Line 1: Line 1:
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"/>
{{Project Snowstorm Nav}}
{{Project Snowstorm Nav}}
__TOC__
__TOC__
<br clear="all"/>
<br clear="all"/>
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.
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):
;[[#Repo-viewer-development|viewer-development]]:is the integration working repository
;[[#Repo-viewer-beta|viewer-beta]]:records the sources in the current beta release, and may be used to repair problems in it
;[[#Repo-viewer-release|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.


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):
[[Image:Viewer-Process-Overview-2.png|frameless|800px|caption="Overview of Viewer Repositories and Change Flow"]]
* [[#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.  Detailed descriptions of each, and the processes for moving changes between them, are below.
<br clear="all"/>


== Repositories ==
== Phases ==


[[Image:Viewer-Process-Overview-1.png|frameless|800px|caption="Overview of Viewer Repositories and Change Flow"]]
=== Development Phase ===


===Development===
# Developers fork from the [[#Repo-viewer-release|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.


'''Location:''' [http://hg.secondlife.com/viewer-development http://hg.secondlife.com/viewer-development]
:'''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.'''


:'''This is the conceptual ‘trunk’ from which all development, both inside and outside Linden Lab, should be derived.'''
See [[How To Submit A Viewer Change]].


It is built continuously, with the resulting viewers being publicly available from [[Downloading test builds]] and the [[Snowstorm Team]] page.
=== Integration Phase ===


Any active viewer development, whether for feature development or bug fixes, pulls from (clones) 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.
# When team QA has passed, and the [[#Development Integration Criteria|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 [[#Repo-viewer-development|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).


Any build from this repository should be sufficient quality to be a candidate for the next Beta viewer release.
:'''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.'''


: '''Note:''' Developers should consider the viewer-development branch to be a "clean" trunk. It's not "pristine" -- we don't gate checkins through a QA process. But developers should be very confident '''before''' checking in to viewer-development, because other projects, both internal and external, are pulling from this repository on a daily basis.  Those other developers rely on you to ensure that syncing up to viewer-development should not introduce problems. '''Developers must be willing to support their checkins.'''
=== Beta Phase ===


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


'''Location:''' ''determined by the development team, but somewhere at hg.secondlife.com or bitbucket.org is encouraged''
# 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:
## The "''version''-beta''#''" tag is added, and the changesets are pushed to the [[#Repo-viewer-beta|viewer-beta]] repository


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


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.
=== Release Phase ===


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 [[Channel and Version Requirements|change this to a project-specific value]] in those viewers. 
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


Linden development teams releasing a Project Viewer should use the (internal) [https://wiki.lindenlab.com/wiki/Project_Viewer_Release_Checklist Project Viewer Release Checklist].
== Repositories ==


When development is complete '''and the [[#Development Integration Criteria|Development Integration Criteria]] have been satisfied''' changes from a Project repository are moved back to the Development repository.  See [[How To Submit A Viewer Change]].
=== Canonical Integration and Release Repositories ===


===Beta and Release===
;<span id="Repo-viewer-release">viewer-release</span>
:'''This is the primary stable code repository; all normal development should be based on this repository.'''
: [http://hg.secondlife.com/viewer-release 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.


To create the Beta and Release Viewers, the changes on the Development repository are moved through the [[#Beta Repository|Beta]] and [[#Release|Release]] repositories following the [[#Beta and Release Process|Beta and Release Process]].  
;<span id="Repo-viewer-beta">viewer-beta</span>
: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.


These are continuous processes - barring serious problems or extra time needed to test large or high risk changes, each week the current Beta version is promoted to Release and the current Development is moved to Beta to begin the next cycle.  See the [[#Example Release Schedule]] below for the normal timing of these moves.
;<span id="Repo-viewer-development">viewer-development</span>
: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.


'''Location:''' [http://hg.secondlife.com/viewer-beta http://hg.secondlife.com/viewer-beta]


: The Integration and QA team tags Development and pulls from that tag 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). 
===Project Repositories===


: Final QA and stabilization are done using builds from the Beta repository; builds from this repository are released weekly on the “Second Life Beta Viewer” channel.
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 bug fixes on this repository are immediately pulled to the Development repository by the Snowstorm 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.


'''Location:''' [http://hg.secondlife.com/viewer-release http://hg.secondlife.com/viewer-release]
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 [[Channel and Version Requirements|change this to a project-specific value]] in those viewers.  


: When the Snowstorm Team decides that the Beta branch is ready for release (which we expect to be after 2-4 weeks of testing and stabilization), 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.
Linden development teams releasing a Project Viewer should use the (internal) [https://wiki.lindenlab.com/wiki/Project_Viewer_Release_Checklist Project Viewer Release Checklist].


==Development Integration Criteria==
==Development Integration Criteria==
Line 82: Line 111:


When these criteria have been met, the development team may integrate into the Development repository; see [[How To Submit A Viewer Change]].
When these criteria have been met, the development team may integrate into the Development repository; see [[How To Submit A Viewer Change]].
If a checkin causes excessive instability or breaks customer experience in important ways, it may be reverted and the developer will have to fix the issues and re-integrate. We hope not to have to do this often, but we will make the reversion decision quickly, because reversion usually requires reverting all later checkins as well.
==Beta and Release Process==
The process by which the Development code is  promoted to an official numbered Viewer release is:
# The Integration and QA team tags Development at the chosen changeset with a ''<version>''<tt>-start</tt> tag, and increments the viewer version number on the viewer-development branch.
# The Release Manager
## Pulls from the ''<version>''<tt>-start</tt> tag to the viewer-pre-beta repository and builds a Beta Candidate viewer from that branch.
## 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 Owner 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 viewer-pre-beta repository.
#** Fixes made to the viewer-pre-beta repository are immediately merged to Development by the Snowstorm Team.
#* ''Ship'': the Beta Candidate 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, adds the appropriate tag to record the changeset with the appropriate ''<version>''<tt>-beta</tt>''#'' tag, and pulls that tag to the viewer-beta repository.
# 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).
# The next week the Viewer Product Owner decides whether or not the Beta is of sufficient quality to ship as an official viewer; if so, the Release team:
## Tags the Beta branch
## Pulls from the tag on viewer-beta to viewer-pre-release
## Builds a Release Candidate from the viewer-pre-release repository.
## Releases on the “Second Life Viewer” channel, and pulls the corresponding sources to the viewer-release repository.
== Example Release Calendar ==
The following illustrates how and on which days the various events described above occur as a change moves from Development to Release (all times are San Francisco local time).  The contents of each release are shown as releases A, B, C, and D.  For simplicity, any releases prior to A are not shown.  In a complete calendar, all weeks would like like week 3 below.
{|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0" cellpadding="5" border="1"
|-
!rowspan="2" style="width: 5%"  scope="col"|Week
!rowspan="2" style="width: 15%" scope="col"|Day
!scope="col" colspan="5"|Viewer Repositories
|-
!style="width: 16%;" scope="col"|Development
!style="width: 16%;" scope="col"|Pre-Beta
!style="width: 16%;" scope="col"|Beta
!style="width: 16%;" scope="col"|Pre-Release
!style="width: 16%;" scope="col"|Release
|-
!rowspan="9"|1 <!-- ==================== Week 1 ======================== -->
|rowspan="2"|'''Monday''' <!-- week 1 -->
|style="background: #ff9;" colspan="2"|06:00 Version A Development &rarr; Beta Candidate
||
||
||
|-
|style="background: #7f7;" rowspan="8"|Version B commits
|style="background: #ff9;"|Version A Beta Candidate Built
||
||
||
|-
|'''Tuesday''' <!-- week 1 -->
|style="background: #ff9;" rowspan="2"|Version A
:QA of Beta Candidate
||
||
||
|-
|'''Wednesday''' <!-- week 1 -->
||
||
||
|-
|rowspan="2"|'''Thursday''' <!-- week 1 -->
|'''''Promotion Meeting 12:00'''''
||
||
||
|-
|style="background: #ff9;" colspan="2"|Version A Beta Candidate &rarr; '''''Beta'''''
|
|
|- style="background: #ddd;"
|'''Friday'''
''no changes''<!-- week 1 -->
||
|style="background: #ff9;" rowspan="7"|Version A Beta Test
||
||
|- style="background: #ddd;"
|'''Saturday'''
''no changes'' <!-- week 1 -->
||
||
||
|- style="background: #ddd;"
|'''Sunday'''
''no changes'' <!-- week 1 -->
||
||
||
|-
!rowspan="10"|2 <!-- ==================== Week 2 ======================== -->
|rowspan="2"|'''Monday''' <!-- week 2 -->
|style="background: #7f7;" colspan="2"|06:00 Version B Development &rarr; Beta Candidate
||
||
|-
|style="background: #9ff;" rowspan="9"|Version C commits
|style="background: #7f7;"|Version B Beta Candidate Built
||
||
|-
|'''Tuesday''' <!-- week 2 -->
|style="background: #7f7;" rowspan="2"|Version B
:QA of Beta Candidate
||
||
|-
|'''Wednesday''' <!-- week 2 -->
||
||
|-
|rowspan="2"|'''Thursday''' <!-- week 2 -->
|'''''Promotion Meeting 12:00'''''
|style="background: #ff9;" colspan="2"|Version A Beta &rarr; Release Candidate
|
|-
|style="background: #7f7;" colspan="2"|Version B Beta Candidate &rarr; '''''Beta'''''
|style="background: #ff9;" rowspan="2"|Version A Release Candidate Built
||
|- style="background: #ddd;"
|rowspan="2"|'''Friday'''
''no changes''<!-- week 2 -->
|rowspan="2"|
|style="background: #7f7;" rowspan="8"|Version B Beta Test
|rowspan="2"|
|-
|style="background: #ff9;" rowspan="5"|Version A Release Candidate QA
|- style="background: #ddd;"
|'''Saturday'''
''no changes'' <!-- week 2 -->
||
||
|- style="background: #ddd;"
|'''Sunday'''
''no changes'' <!-- week 2 -->
||
||
|-
!rowspan="10"|3 <!-- ==================== Week 3 ======================== -->
|rowspan="2"|'''Monday''' <!-- week 3 -->
|style="background: #9ff;" colspan="2"|06:00 Version C Development &rarr; Beta Candidate
||
|-
|style="background: #99f;" rowspan="9"|Version D commits
|style="background: #9ff;"|Version C Beta Candidate Built
||
|-
|-
|'''Tuesday''' <!-- week 3 -->
|style="background: #9ff;" rowspan="2"|Version C
:QA of Beta Candidate
|style="background: #ff9;" colspan="2"|Version A Release Candidate &rarr; '''''Release'''''
|-
|'''Wednesday''' <!-- week 3 -->
||
||
|-
|rowspan="2"|'''Thursday''' <!-- week 3 -->
|'''''Promotion Meeting 12:00'''''
|style="background: #7f7;" colspan="2"|Version B Beta &rarr; Release Candidate
||
|-
|style="background: #9ff;" colspan="2"|Version C Beta Candidate &rarr; '''''Beta'''''
|style="background: #7f7;" rowspan="2"|Version B Release Candidate Built
||
|- style="background: #ddd;"
|rowspan="2" |'''Friday'''
''no changes''<!-- week 3 -->
|rowspan="2"|
|style="background: #9ff;" rowspan="4"|Version C Beta Test
|rowspan="2"|
|-
|style="background: #7f7;" rowspan="5"|Version B Release Candidate QA
|- style="background: #ddd;"
|'''Saturday'''
''no changes'' <!-- week 3 -->
||
||
|- style="background: #ddd;"
|'''Sunday'''
''no changes'' <!-- week 3 -->
||
||
|}

Revision as of 09:43, 10 March 2012

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.


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.

caption="Overview of Viewer Repositories and Change Flow"

Phases

Development Phase

  1. Developers fork from the viewer-release 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.
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

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

  1. The tags "viewer-beta-candidate", "version-start", and one for the DRTVWR issue id (used for tracking within the Lab).
  2. 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:

  1. The "viewer-release-candidate" tag in the viewer-beta repository is moved to trigger the release candidate build
  2. 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)
  3. 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
  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; 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:

  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.

Retrieved from "https://wiki.secondlife.com/w/index.php?title=Viewer_Integration_and_Release_Processes&oldid=1163969"