SL project news week 21 (1): viewer release process

Work continues on implementing the new viewer release process, although it is unlikely to debut this week (week 21). Commenting on the state-of-play at the Open-source Development meeting on Monday May 20th, Oz Linden said, “There are some new services to stand up, and I don’t have enough experience with that to be able to estimate it well.” He also indicated that the necessary changes to the log-in process I reported on in week 20  are still being progressed with care.

However, as of May 20th, 2013, the viewer beta repository has been discontinued by the Lab. This means that the next beta viewer to appear – which is due to be the Materials Processing viewer due out possibly later this week – will be built directly from the Materials project repository and not a merge with the existing beta viewer, although it will go through the existing beta channel for release and made available via viewer download page.

Viewer Naming

Under the new system,  viewer names will be broadly streamlined, with beta and release candidate versions of viewer being broadly identified by the viewer type and project name (e.g “Second Life Beta Materials” or “Second Life Release Candidate Materials”), prior to being updated as the release viewer.

“Willing to Update”

As previously noted in this blog, when a user downloads a specific viewer, they will only receive updates specific to that viewer until such time as it reaches a release status (although user can theoretically run several viewer side-by-side, and receive the required updates to each of them as they become available). However, the beta viewers will in future a new Preferences option, “Willing to update to release candidates” (Preferences > Setup).

The new beta viewer option for updating to RC status
The new beta viewer option for updating to RC status

Precisely how this option works is unclear (I have contacted Oz Linden on the matter but have yet to hear back), but it appears to suggest that if unchecked, then notification of any RC updates to the viewer will not be forwarded to the user  / automatically downloaded and installed, and will thus leave the user running with the viewer in a beta state until such time as a mandatory update is forced as the viewer becomes the de facto release viewer.

How Many?

The new release process means that there will be more viewer options to download via the Alternate Viewers wiki page. How many depends on the number of projects and general work is going on with the viewer. However, it also means that once operational, there should be fewer incidences when a specific project or issue interrupts the flow of viewer through to release status, as occurred towards the end of the 2012, when the viewer releases became “stuck” in the beta release channel as a result of a single crash issue.

Related Links

One thought on “SL project news week 21 (1): viewer release process

  1. Thank You for Your continued and excellent coverage of the workings of SL. There is one observation I have to make, though, as a Linux user and I’m sure You couldn’t have made it, because You are not familiar with the workings of the various flavours of this particular OS.

    My observation has to do with the “willing to update” section of Your post – the automatic update download and installation. While I’m sure the Lindens can easily do it for Windows users, for Linux users things are a tad more complicated: while it could be easy to set up a system that automatically downloads the tarball with the viewer, there are issues of archive maintenance, packaging, depackaging, dependency checking and installation in the world of Linux. This is because in Linux there are some different approaches to packaging and installing pre-compiled software: those of us who use Debian-based Linux distributions (Debian, Ubuntu and their derivatives, such as SolusOS, Linux Mint and Bodhi Linux) use .deb packages and these can be either pre-compiled for the 32-bit i386 architecture or for the 64-bit architectures (such as AMD) – and let me tell You that recently there was a change w.r.t. support of 32-bit architectures (multiarch) on 64-bit Linux distros, and this made installation of this support a major pain for certain Ubuntu releases, thereby rendering usability of SL’s viewer rather dicey; I speak from personal experience here. Users of OpenSUSE, Fedora/Red Hat Enterprise Linux/CentOS and Oracle’s own RHEL fork that was once marketed as “Unbreakable” (yeah, right) use RPM packages.

    If LL (and perhaps TPV developers) are to provide automatic updates for their viewer, they’d need to set up a proper system to accommodate these two major currents, as well as continue to offer tarballs that people can install manually (as is the case right now).

    They’d have to offer i386 and amd64 .deb packages in PPAs (Personal Package Archives) for Debian- and Ubuntu-based distros and, of course, RPM packages for the others – and users will, of course, have to add these PPAs or other sources to their package manager’s software sources for automatic updates. And they’d also need someone highly knowledgeable with the peculiarities of each major current to ensure that the dependencies will be satisfied.

    This is my $0.02 – I hope it helps.


Comments are closed.