As reported before, a new viewer pipeline with various release candidates is coming online. It is mostly in place now. I don’t see where any recent announcements have been made by the Lab. Inara over on Living in the Modem World, has written about it. But, I think we are all a bit unsure how things are going to work. I know I am. I’m experimenting with things now.
I’ve updated my machine to use Win 7-64 in a dual boot scenario. This gives me a clean starting place for experimenting with the new viewer pipeline. Until today the only viewer I had installed was the main SL Viewer. I have all the other viewers on the other side of the dual boot in Vista 32. So, I can get to them. But, not from Win7.
I have clean AppData folders as a new Win7 user. Plus caches and log areas are new and fresh.
Differences
Before the Candidate Pipeline the install files were using names like: Second_Life_3-5-4-276827_Beta_Maintenance_Setup.exe. This made it easy to download install files and keep them separate and they were easily identifiable, which helps when going back a version.
That is no longer the case. The maintenance candidate I downloaded this morning is named: Second_Life_3-6-2-278602_Setup.exe, which is the same file name, except for version number, used for the main SL Viewer. If you want to keep them separated, you’ll have to name them when you download them.
The install and operation of these new beta viewers are different too. The Maintenance Beta will install over the top of the main SL Viewer. You do have an option to install the viewer beta into a folder of your choice. The install will also overwrite your shortcuts and the Start Menu links. There are no options for those. Those Beta version icons will no longer appear as Second Life [some project name]. The two I’ve installed use the same menu name: Second Life Viewer.
If you want to have multiple Linden Lab SL Viewers that you use, you need to rename your main viewer’s links and menu entries BEFORE installing the Beta. Otherwise they will be over written.
Another change is the viewers all use the same ‘settings.xml’ file. A side affect of that is they all use the same cache files, which is probably a good thing. But, I remember lots of problems from years back before I started separating viewer caches and it then became the default procedure for most viewers. Will we see problems from shared caches? May be and may be not.
With the new beta pipeline for viewers you will very much be swimming upstream if you want to use more than one Linden SL Viewer at a time. You will need to use the command line options for the viewer found in the SL Wiki page: Viewer Parameters. The –settings command line option will allow you to specify a settings file, which will then allow you to specify a different viewer cache.
One of the things we do not know is how exactly updates will overwrite previous versions. Consider this. You download and install the Maintenance Viewer as a separate install. As the candidate evolves through the process it will eventually become the Linden default/main viewer. You would then have two copies of the main viewer installed. But, would the update be placed in your Maintenance install folder? Or replace the main viewer folder? I don’t know yet.
For those of us that want to run multiple Linden viewers at the same time, things are looking complicated.
Why do this?
If you wonder why the Lindens are making things different and apparently more complicated, you probably are not looking at it from the Linden side of things.
The Lab needs to have more than one viewer channel moving code into the final stable viewer that is released as the default or main viewer. The current main viewer is now estimated to be four months behind where the server is. There are numerous third party features and improvements that have not been incorporated as higher priority updates are pushing in ahead of them.
In the last part of 2012 a memory problem held up the viewer for months. There was no easy way to work around the problem. Nor could new code be added without complicating the debugging process needed to find the memory problem and solve it. So, a single difficult to solve problem held up and complicated viewer development for months.
The new process handles problems the Lab faces. Of course it provides a way around a tough bug. So, if some new code creates a problem, it can be held back while new code moves through other channels, candidates. The problem can be researched and fixed in a branch (channel) that is static, where the only changes are fixes targeted at the problem. Once solved, the code that has passed by the problem channel can be added into the problem candidate and the channel retested. It can then start moving forward again. But, other features and fixes did not have to wait.
The other problem it solves is providing the Lab a way to move testers around. As it is now we decide if we want to use the Mesh Deformer Project Viewer or the CHUI Project Viewer or whatever. But, what if the Lab’s engineers need more testers than are choosing to test a specific version? And how do you know which viewer needs the most testing and when? Waiting to get the word out via the forum, which few people pay attention to (how many posts have more than 500 or 1,000 readers?). Requesting help in the User Group meetings introduces a time delay and most meetings are only attended by 15 to 30 people. Then word has to get out via bloggers. SL blogs with more than 2,000 readers are relatively rare. In all only a few thousand people may ever hear their help is needed.
Also, what happens when a problem is specific to a narrow group of video cards or operating systems? As it s now the Lab has no control over who with which equipment decides to test a viewer.
The new pipeline solves the problems of who, which, how many, what hardware, and when to test. Users now select an option in the viewer to participate in testing or not. In Preferences->Setup we have an option in Software Updates to show we are willing to participate in release candidate testing: Willing to update to release candidates.
This option lets the Lindens use the pipeline to select you and update your viewer with the version they need tested. The information we have now is that once they assign you a channel, you are in that channel until it moves out as the main viewer. Then you’ll eventually get assigned another beta viewer. Until then you will be using the main viewer.
Choice
Of course you can choose to participate or not.
In the past if your computer setup experienced a problem with a viewer or some task you needed to perform had a problem you could elect to move into a beta viewer that had a fix. You found the beta viewer, development viewer, or project viewer and installed it. It went into its own folder and you tried it. If it was better, you kept using it. If not, you just clicked on you original viewer icon to run it as they were both installed. But, those simple days are apparently gone.
If you have a specific problem now and grab a beta viewer (release candidate) you need to know how to do a custom install. Otherwise, if the beta is worse, you will have do another install to get the previous or main version viewer back.
You still have the choices. But, to implement those choices as we have previously done will take more knowledge of what the viewer is doing and how to install multiple versions of the Linden viewers.
But, the Lindens think being a tester will now be easier, if you just let them control your updates. I agree it will be. I expect it to work well until they make a mistake. Of course they likely think a roll back will be easy enough.
I think if I find a problem that is NOT a general disaster late Friday night, I expect I’ll have to wait until Monday some time for the roll back to rolled out. I’m not big on waiting.
Summary
It is too soon to say this is a good or bad thing for users. But, you have probably gathered I have doubts about how good it is for users. I do think it will speed up viewer development. I also think the majority of users won’t even notice there has been a change.
Time will tell us the answer.
None of this pipeline thing affects third party viewers.
I have always downloaded every new viewer install (from Linden Lab and TPVs) to a new directory. It means if you do hit issues or want to go back to compare a feature you can. It has also meant that I can ignore most of those dire warnings about not doing a clean install I just popped a new start icon on the desktop and cleared off old ones after a while – it is a simple way to work.
The merging of settings.xml is another, and slightly more worrying issue (though I’m fairly sure you can still make the viewer point elsewhere if you want). This is because there have been times in the past where some settings were having their parameters, range or function changed in dev and yet be different in the full viewer. Of course I’m sure LL are aware of these possible complications and will change such settings by changing their names first in future (that was the names of the settings, not the Lindens :)).
*chuckles* When I first saw the title of this article, I asked to myself, “What ? A new render pipeline ?… Where ?… I was not even aware !!!” and then realized after reading the first few lines that you were actually speaking about the new “release and integration process” (http://wiki.secondlife.com/wiki/Viewer_Integration_and_Release_Processes)… Careful with the words you employ… ;-P
As for what it changes for TPV developers, well, not much indeed (but for the number of branches to follow the commits for): as long as LL releases the code in the repositories at the same time as they release the project viewers binaries (which has not always been the case in the past), I’m fine with it.