At BriForum in June 2008, I received a nice compliment from Shawn Bass for keeping the Streaming Client version numbers small. The idea was that with the release of significant new function in Inter-Isolation Communication, the streaming client version number was changing from 1.1 to 1.2 and he thought that was a pretty cool thing to go out the door in a point release. I thought so too, but we didn’t “go point” just because it was cool, I have history that has shaped my opinion of software versioning and taught me to NEVER change anything that isn’t an integer. Version data should be a single field, and should only get “bigger”.
Streaming Client 1.2 is the 4th release of the XenApp application isolation systems. Here’s a rundown.
AIE – Presentation Server 4.0
Server side only.
Profiling via AIESetup, execution via AIERun. or
Execution of a locally installed application, under isolation
Streaming Client 1.0 – Shipped with Presentation Server 4.5
Embrace desktops for execution platform as well as server side
Includes “offline” support.
Streaming Profiler GUI for capturing installation activity.
Extensive profiling activity compared to AIE – example: automatic virtual reboot.
COM isolation rewritten and registry hooking also redone.
AIE depreciated, but still around. File system components shared.
Streaming Client 1.1 – Presentation Server 4.5 HRP1
Unified licensing with Citrix Presentation server
Improved performance and application compatibility
Streaming Client 1.2 – XenApp 5.0
Inter-Isolation Communication (big ticket item)
HTTP supported as a streaming protocol in addition to SMB/CIFS UNC based copies
WANScaler (Branch Repeater) – Efficient CAB distribution; bonus, faster first time launch
Streaming Client 1.3 – XenApp 5.0
Not released yet
Like the XenApp Plugin for Hosted Apps (PNAgent), the Streaming Client can release independent from its XenApp mothership. Technically speaking, this hasn’t happened, but it could and I’ll go out on a limb and say that it will and we’ll likely call that client 1.3.
Someday, a next release with something significant and new will come out.
Will it be “1.4”?
I’m actually leaning to 3.0. This acknowledges that IIC should have been important enough to get a major release bump and that the next signficiant release will again bump the major version number. Doing these will be “right” so the software doesn’t appear as a 1.x even though it will be on its 6th release.
Still, I do favor only updating one field of a version. Do it this way, and upgrade checking software can’t possibly mess up.
The Citrix updates key off of the build major release number and the integer build number. You can see these in the version data attached to any file built for XenApp. In XenApp 5.0, they all start with “5” and the release build was 5357.2 or “.3” depending on when you called it done. How we get .3 into an integer field is a bit interesting. This means that the descriptive version number (the marketing name of “5.0” or “1.2”) is just “text” and since its just text, it doesn’t do much important to trigger updates.
There SHOULD be no harm in bumping the major version number and resetting the minor to zero and my paranoia can go to rest – or at least changed to worry what happens when the major build number goes to 6 and the build goes out the door with a build number less than the build number of XenApp 5.0.
I’ll send a virtual cup of coffee to the first person that can spot the bug on XenApp 5.0 and the Streaming Client binaries as related to this blog post. Harmless, but still a bug.
Product Architect – Application Streaming
Citrix Systems, Fort Lauderdale, FL