|
|
| (19 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| {{RightToc}}
| |
|
| |
| 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. | | 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"/> |
| 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):
| | {{Project Snowstorm Nav}} |
| * [[#Development|Development]] is the integration trunk
| | __TOC__ |
| * [[#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"/> | | <br clear="all"/> |
|
| |
|
| == Repositories == | | == The Process == |
| | |
| [[Image:ViewerRepoOverview.png|frameless|800px|caption="Overview of Viewer Repositories and Change Flow"]]
| |
| | |
| ===Development===
| |
| | |
| '''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 from [[Downloading test builds]] and the [[Snowstorm Team]] page.
| |
| | |
| 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.
| |
| | |
| Any build from this repository should be sufficient quality to be a candidate for the next Beta viewer release.
| |
| | |
| ===Project===
| |
| | |
| '''Location:''' ''determined by the development team, but somewhere at hg.secondlife.com or bitbucket.org is encouraged''
| |
| | |
| 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 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 [[Channel and Version Requirements|change this to a project-specific value]] in those viewers.
| |
|
| |
|
| 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]].
| | 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). |
|
| |
|
| : '''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.'''
| | 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]] |
|
| |
|
| : ''If you are not prepared to respond to bug reports on a high-priority basis all the way through the release process, '''you should not check in'''.''
| | 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). |
|
| |
|
| ===Beta and Release===
| | 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. |
|
| |
|
| 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]].
| | 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. |
|
| |
|
| 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.
| | 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. |
|
| |
|
| '''Location:''' [http://hg.secondlife.com/viewer-beta http://hg.secondlife.com/viewer-beta]
| | [[Image:Viewer-Repo-Flow-8.png|Project Integration, Beta, and Release]] |
|
| |
|
| : 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).
| | The sections below detail the specifics of each phase. |
|
| |
|
| : 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 Integration=== |
|
| |
|
| : Any bug fixes on this repository are immediately pulled to the Development repository by the Snowstorm Team. | | # 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. |
| | #: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. |
| | # 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 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: |
| | #::[[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). |
| | # 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. |
| | #: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]] |
|
| |
|
| '''Location:''' [http://hg.secondlife.com/viewer-release http://hg.secondlife.com/viewer-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 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.
| | ===Beta Test=== |
|
| |
|
| ==Development Integration Criteria== | | 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: |
| | :[[Image:Viewer-Icon-Beta.png]] [[Image:Viewer-Menu-Beta-1.png]] |
|
| |
|
| 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:
| | ===Release Candidate=== |
|
| |
|
| # '''Functionality must have been reviewed and accepted by the Product Owner'''
| | 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: |
| #: 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.
| | :[[Image:Viewer-Icon-Release.png]] [[Image:Viewer-Menu-Release-1.png]] |
| # '''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).
| |
| # '''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_Script_Template | test plan template]] to help make this trouble free.
| |
| # '''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://lecs.opensource.secondlife.com/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 may integrate into the Development repository; see [[How To Submit A Viewer Change]].
| | 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. |
|
| |
|
| 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.
| | There may be more than one Release Candidate at the same time. |
|
| |
|
| ==Beta and Release Process== | | ===Release=== |
|
| |
|
| The process by which the Development code is promoted to an official numbered Viewer release is:
| | When it is determined that a particular Release Candidate is ready, it is promoted to the default Release viewer. |
|
| |
|
| # 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.
| | 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. |
| # The Release Manager
| |
| ## Pulls from the ''<version>''<tt>-start</tt> 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 == | | == Mercurial Repositories == |
|
| |
|
| 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 {{SLT}}). 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. | | ;<span id="Repo-viewer-release"><tt>viewer-release</tt></span> |
| | :<tt>http://bitbucket.org/lindenlab/viewer-release</tt> |
| | :The viewer-release repo records the code used to produce all released viewers through the latest Release version currently in production. |
| | :''Write access to the this repository is closely controlled.'' |
| | :'''This is the stable repository 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.}} |
|
| |
|
| {|style="border-collapse: separate; border-spacing: 0; border-width: 1px; border-style: solid; border-color: #000; padding: 0" cellpadding="5" border="1"
| | ;<tt>project viewers</tt> |
| |-
| | :The links to the project viewers repositories can be found on the [[Linden_Lab_Official:Viewer_Source_Repositories]] |
| !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 → 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 → Beta
| |
| |
| |
| |
| |
| |-
| |
| !Friday <!-- week 1 -->
| |
| ||
| |
| |style="background: #ff9;" rowspan="7"|Version A Beta Test
| |
| ||
| |
| ||
| |
| |-
| |
| !Saturday <!-- week 1 -->
| |
| ||
| |
| ||
| |
| ||
| |
| |-
| |
| !Sunday <!-- week 1 -->
| |
| ||
| |
| ||
| |
| ||
| |
| |-
| |
| !rowspan="10"|2 <!-- ==================== Week 2 ======================== -->
| |
| !rowspan="2"|Monday <!-- week 2 -->
| |
| |style="background: #7f7;" colspan="2"|06:00 Version B Development → 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 → Release Candidate
| |
| |
| |
| |-
| |
| |style="background: #7f7;" colspan="2"|Version B Beta Candidate → Beta
| |
| |style="background: #ff9;" rowspan="2"|Version A Release Candidate Built
| |
| ||
| |
| |-
| |
| !rowspan="2"|Friday <!-- 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
| |
| |-
| |
| !Saturday <!-- week 2 -->
| |
| ||
| |
| ||
| |
| |-
| |
| !Sunday <!-- week 2 -->
| |
| ||
| |
| ||
| |
| |-
| |
| !rowspan="10"|3 <!-- ==================== Week 3 ======================== -->
| |
| !rowspan="2"|Monday <!-- week 3 -->
| |
| |style="background: #9ff;" colspan="2"|06:00 Version C Development → 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 → Release
| |
| |-
| |
| !Wednesday <!-- week 3 -->
| |
| ||
| |
| ||
| |
| |-
| |
| !rowspan="2"|Thursday <!-- week 3 -->
| |
| |'''''Promotion Meeting 12:00'''''
| |
| |style="background: #7f7;" colspan="2"|Version B Beta → Release Candidate
| |
| ||
| |
| |-
| |
| |style="background: #9ff;" colspan="2"|Version C Beta Candidate → Beta
| |
| |style="background: #7f7;" rowspan="2"|Version B Release Candidate Built
| |
| ||
| |
| |-
| |
| !rowspan="2"|Friday <!-- 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
| |
| |-
| |
| !Saturday <!-- week 3 -->
| |
| ||
| |
| ||
| |
| |-
| |
| !Sunday <!-- week 3 -->
| |
| ||
| |
| ||
| |
| |}
| |
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 Process
All projects begin by forking the viewer-release 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).
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 (normally, 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 repository is then pulled to the viewer-release 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.
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 integration repository by forking the viewer-release 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.
- Individual developers on the project fork working repositories from the project integration repository, and build Test viewers for their contributions to the project prior to integration.
- Individual developer 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 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).
- The project integration engineer maintains a canonical Project viewer build on TeamCity that builds the integration repository 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. 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 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.
There may be more than one Release Candidate at the same time.
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 viewer-release, 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 out those changes.
Mercurial Repositories
- viewer-release
- http://bitbucket.org/lindenlab/viewer-release
- The viewer-release repo records the code used to produce all released viewers through the latest Release version currently in production.
- Write access to the this repository is closely controlled.
- This is the stable repository that serves as the base for all development.
NOTE: The viewer-beta and viewer-development repositories used in earlier versions of this process are no longer used; viewer-release is the single canonical repository.
- project viewers
- The links to the project viewers repositories can be found on the Linden_Lab_Official:Viewer_Source_Repositories
