Update July 23rd: As release candidate viewers are now available for download on the Alternate Viewers wiki page, I’ve added some notes on manually installing and running multiple release candidates to this article.
The new viewer release process announced by the Lab in May 2013 has officially been implemented.
Officially called the Viewer Integration and Release Process, It is designed to improve how the Lab can put new viewers before users and progress them through to a release status while avoiding bottlenecks such as those witnessed in late 2012, when an issue with the Viewer Beta channel effectively stopped any new viewer releases for around a two-month period.
With the new system, early versions of viewers will still be made available through “dedicated” project and beta viewers, all of which will be available for download via the Official Alternate Viewers Page. However, the major change to the process is the use of “release candidates”.
When a viewer is ready for final testing, a release candidate will be readied. Rather than residing in their own dedicated viewer channel, these release candidates will be updates in the regular release channel, residing in a named “cohort” within the channel.
This means two things. Firstly, release candidates are available for download alongside one another and the default release viewer. Who might receive a given release candidate is a random selection based on a viewer setting (see below) and a pre-determined quota of downloads for the candidate (once the quota has been reached for a given candidate, the system will no longer select it for download).
Secondly, when a specific release candidate is deemed ready for release (based on bug reports filed, issues reported and fixed, stats gathered, etc.), there is no longer any need to rebuild it as a “release” viewer, as it is already in the release channel. It is simply moved from its named cohort to become the default release version on the SL viewer download page. Any remaining release candidates are then rebuilt using the new default release code, and continue with testing until one is deemed ready to become the next release.
From a user perspective, release candidates are largely indistinguishable from one another and the default release viewer (other than their version number and the features they contain), and the chances are that some users will be unaware that they have been selected by the system to run a release candidate; they will simply see it as receiving an automatic / mandatory viewer update, and install it.
“Willing to Update” and Release Candidate Downloads
As mentioned above, users who receive a release candidate viewer are selected at random, based on a defined quota of downloads for a given release candidate. However, whether or not a user might be selected to receive a release candidate viewer depends on whether or not they have left the “willing to update” option enabled in their current viewer.
Located in Preferences > Setup, “willing to update to release candidates” (to give the option its full name) is enabled by default. But just because it is, does not automatically mean someone will be selected to test a release candidate viewer. This is because the download quota defined for any given release candidate will always be relatively small when compared to the SL user base as whole.
However, if you don’t wish to run any release candidate viewers at all, you can disable this option, and only receive viewer updates when the default release viewer is updated.
Another point to remember with release candidates is that users won’t be moved between release candidates as a result of updates. So if you leave the “willing to update” option enabled and you happen to be selected for testing “release candidate A”, you won’t suddenly start receiving updates for “release candidate B”; you’ll stay with the updates for “release candidate A” until such time as it becomes the default release viewer. Only then might you be selected to receive another release candidate download at some point in the future.
Download Page and Alternate Viewers Page updates
As a result of the move to the new release process, the SL viewer download page has been updated, and there is no longer any link to download the “Beta Viewer”. Instead, there is a link which takes you to the Official Alternative Viewer wiki page, which instead lists all available beta and project viewers.
The Importance of Version Numbers
An important aspect of viewer bug reporting has been to give details of the viewer you’re running, including the version number. This information is requested in the “Environment” section of the bug report form. Given that the new viewer release process means there can be a number of release candidates in use at any given time, as well as various beta and project viewers, it is even more important that this information is given when raising a bug report.
Viewer information can be found in the About Second Life floater (Help > About Second Life), if you’re not already familiar with it. Further, the information on this floater can be copied directly to your clipboard ready to be pasted in a bug report to save you having to manually enter it.
Notes on Manually Installing Release Candidates
Viewer release candidates are now listed on the Alternative Viewers wiki page, and can be downloaded and installed, if so desired. If you do opt to do so, please note that release candidates are contained in “cohorts” within the viewer release channel, and are designed to overwrite any release candidate viewer you have installed. Therefore, if you wish to manually install multiple release candidate viewers side-by-side and with the de facto release viewer, you much ensure, in accordance with your operating system, that:
- Any shortcuts / start menu links (e.g. Windows) you have for the viewer are renamed before you install any release candidates
- Each release candidate is installed into a unique folder
- Any shortcuts / start menu links (e.g. Windows) which are created as a part of the installation process are given unique names before installing the next release candidate
Notes:
- If you provide unique destinations for each release candidate installation thorugh the installer package (e.g. Windows), make sure the installer is listing the correct destination folder when manually downloading and installing a subsequent release / update
- The Windows auto-updater will automatically install into the last folder defined in the viewer installer (so if you have manually installed “Release Candidate A” and then “Release Candidate B” into separate folders, then get an update for “Release Candidate A” via the auto-updater, it will install into the folder for “Release Candidate B”)
- Disabling the auto-updater in Preferences may not stop this from happening.
- Instead, go to viewer install folder/app_settings, then edit settings.xml, and find the entry UpdaterServiceURL and change https://update.secondlife.com to https://secondlife.com/no-thanks (or similar) and save. You may need Admin privileges to do this.
Changes to this Blog
I maintain a list of viewers recognised as being used with Second Life (predominantly, but not exclusively, based on the Third-party Viewer Directory), which is updated as a when I become aware of new viewer releases being made. The section of this page which deals with the SL viewer has been updated to reflect the new viewer release process, and now includes all SL viewers currently listed in the SL viewer download page and the Official Alternate Viewer wiki page (with the exception of the Amazon channel viewer, which is the version of the viewer offered through Amazon.com).
Related Links
- A New Process for Viewer Releases – LL, May 1st, 2013
- Viewer Release and Integration Process – SL wiki
Inara Pey: Living in a Modemworld 
i have my willing to receive updates checked, my seatbelt securely fastened and my tray table in an upright position. now how could this not be fun? lol
LikeLike
Beware of update Asiana 214
LikeLike
Outstanding exposition of what users need to know about this – thank you Inara.
LikeLike
Thank you, Oz
And thanks for the feedback on earlier posts – very much helped to keep me on-message here.
LikeLike
I agree wit Oz, for the first time I think I actually understand this process.
LikeLike
Thanks, Shug :). And for the reblog :).
LikeLike
Reblogged this on Rambling with Shug and commented:
Finally an explanation of the new release process for LL viewers. Well done Inara!
LikeLike
I can foresee legal problems in some jurisdictions.
Hitherto, automatic updates have only been the new default viewer version, the final tested and approved product. It feels in a grey area that this permission is changed by Linden Labs to include test versions of the Viewer. Final test versions, but still test versions.
Here in the UK, the Computer Misuse Act 1990, as Amended by the Police and Justice Act 2006 appears relevant, The particular question is about whether this change amounts to the automatic update becoming an unauthorized access to computer material. It isn’t quite what you asked permission for. It would be a Section 1 offence.
Rather than argue with lawyers about the shifting sands of contract law, I choose not to enable automatic updates on software I use. If you have used the BBC iPlayer on a PC, you will know it depends on Adobe AIR, and you may have experienced the mess an Adobe AIR upgrade can make of the files you have downloaded for later viewing.
Fun, isn’t it.
LikeLike
Unless there is a clear big flashing warning on the installation or after it, with good explanations to the user about what it does and the possible risks (and it doesn’t look like they are doing that at all), most people want only to open their viewer to enjoy SL. Not many people go to rummage among the settings or stay informed about anything or reading well written blogs like yours (thank you, btw).
So, while the idea is good, it depends on how they manage it.
Given that RC releases are potentially buggy, and since they enabled this by default and they are sending them to anyone, even to whom has no technical skill or time or patience to tinker too much, I’m afraid more people will ask for support or change viewer (in the best of the cases…).
LikeLike
There is actually no reason why RCs should be any more buggy than has been the case with the old release process. Most updates will still at least be going through a beta release phase (as was the case prior to the new process coming into effect), and many will also additionally have been through a project release phase as well (again, as currently is the case now), which should (again, as is the case with the “old” process) allow many bugs to be identified and fixed prior to the code being considered for a release candidate.
While some bugs will inevitably slip through to a release candidate – that’s also pretty much true for any view moving from a “beta” to a “release” status, be it with LL’s own viewer or a TPV. So again, there should really be that much more noticeable change.
If anything, where such bugs do slip through to a release candidate, the impact in terms of the total number of users on the SL viewer should hopefully be reduced. This is because RCs will only go to a small percentage of that total number of users, so a much smaller number of people will be exposed to the bug & present the oppotunity for it to be fixed prior to the RC becoming the default viewer.
Of course, this last point pre-supposes that those users on the RC will raise bug reports which will help LL track down and stomp on bugs they have missed; but again, that’s been pretty much the case with viewer releases anyway, so again, nothing in that respect has changed too much.
LikeLike