TPVD/Viewer Version Management
Many users do not upgrade viewers as newer versions become available, and TPV users seem to upgrade even less often than Linden viewer users. This may be because TPV developers don't have as much infrastructure to manage upgrades and enforce them. The use of large numbers of old viewer versions creates problems for the introduction of new Second Life features; even attempting to predict the potential compatibility problems, much less test for them, is intractable. It also inhibits adoption of new TPV features and requires them to worry about compatibility with much older versions.
Linden Lab provides access to our viewer version management infrastructure to TPV developers in good standing so that they have the capabilities the Lab has to encourage and enforce use of current versions.
|Limited Availability At present, this program is experimental and available only to a small number of the smaller TPVs. Once we have worked out any kinks in the process, it will be made more widely available. - Oz Linden|
The shared code already provides the viewer functionality needed to support automatic upgrade checks and installation; this program adds the server side capabilities by providing a way to configure TPVs in the Linden Lab Viewer Version Manager (VVM).
In order to be eligible to use the Linden Lab VVM service, a TPV must:
- Be listed in the official Third Party Viewer Directory
- Be primarily focused on Second Life
- Be supporting important new Second Life functionality reasonably promptly
- Be used by a significant user population
Yes - the requirements are deliberately "soft" - subject to a Linden Lab judgment call.
TPVs must not query the Linden Lab update service when connecting to non-Linden grids.
A "Channel" is a named set of viewer versions. A viewer version is a set of four positive integers separated by '.' characters. See Channel and Version Requirements.
Each TPV has a Viewer Identifier value that serves as its own channel prefix (the Linden Lab Viewer Identifier is "Second Life"). The prefix can be used to create any number of unique channels by appending any suffix such as 'Release' or 'Beta' or a feature name like 'Mesh'.
Each eligible TPV may define two channel names beginning with the Viewer Identifier to be managed by the VVM:
- Main Channel
- Such as "viewer-identifier Release"
- Secondary Channel
- Such as "viewer-identifier Beta"
The names for these channels are recorded in the TPV Application jira issue.
Each channel may have any number of versions deployed. Whenever a new version is deployed to a channel, all earlier versions in the channel are offered an optional upgrade to the new version. The TPV developer is encouraged to specify a minimum allowed version; any version earlier than the minimum gets a required update response to the tip version of the channel, and is not allowed to log in to Second Life.
The Main channel has a default cohort and a 'candidate' cohort. The candidate cohort may have only one active version; any earlier version from the candidate cohort is required to upgrade when a newer version is deployed. When deploying a version to the candidate cohort, the TPV may select:
- Candidate Probability
- the percentage of the upgrade requests from the default cohort that should be offered an upgrade to the candidate (users may opt out of candidate upgrades using a preference)
- Desired Cohort Size
- the number of systems to be upgraded. Once the desired number of systems have logged in using the candidate version, no more are offered upgrades to the candidate.
Any channel not configured in the VVM is unmanaged: no upgrades are offered for any version and login is always allowed regardless of version. TPVs may use unmanaged channel values as well as the managed ones (but unmanaged channel builds should not be given wide distribution, or the purpose is defeated).
Version numbers must be unique within a Viewer Identfier across all channels, but TPVs do not need to worry about version number collisions with other viewers.
How to Release a Version
Only that primary contact may make requests to deploy a new version.
To request that a new version be deployed through the VVM:
- Open the application issue for your viewer
- Select 'More Actions > Create Sub-Task'
- Select the issue type "TPV Deploy Request"
- Select the channel/cohort to which the new version should be deployed
- Fill in the 'TPV Version' to the version number (just the number; do not include the channel name)
- Fill in the 'Release Notes' link (this appears in some dialogs when the upgrade is offered)
- If desired, modify the Viewer Minimum Version
- any version less than this will be a required update to the new version, and will be barred from logging in to Second Life
- If you selected the 'Main Channel candidate', set the 'Channel Candidate %' and 'Desired Cohort Size' fields
- If you make the desired size larger, more users will be added; making it smaller will not remove users
- Fill in the installer urls for any platforms you support. Linden Lab does not provide hosting for the download urls; you can use any hosting you have available.
- Contact Oz if this set of platforms does not match what you need.
- Submit the request
The request will be automatically routed to Oz or some other Linden. You will be notified when it has been completed or it is sent back to you for clarification.