Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1105650

Summary: Fix windows productversion to fit -z releases
Product: Red Hat Enterprise Virtualization Manager Reporter: Marc-Andre Lureau <marcandre.lureau>
Component: mingw-virt-viewerAssignee: Marc-Andre Lureau <marcandre.lureau>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 3.5.0CC: berrange, cfergeau, gklein, juwu, mkrcmari, rbalakri, yeylon
Target Milestone: ---   
Target Release: 3.5.0   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: mingw-virt-viewer-0.6.0-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-11 17:44:05 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1142923, 1156165    

Description Marc-Andre Lureau 2014-06-06 15:56:12 UTC
Windows product version is used to check for MSI upgrades, it has the for $major.$minor.$build.

Since virt-viewer has a different version $major.$minor.$micro, we are fitting $micro + $release in $build with this formula: $build = $micro * 256 + $release.

However, -z releases version do not fit, making update 3.3z updates hard to push if the following rhevm release didn't rebase virt-viewer version.

We need to change the formula, Daniel agreed that it could be something like:

 $build = $micro << 12 + ($release[0] << 4 + $release[1])

Comment 1 Marc-Andre Lureau 2014-06-06 15:59:23 UTC
To simplify a bit, -z releases version upgrade are quite broken. In general, customer will have to perform uninstall first to make sure to use the next release...

Comment 2 Marc-Andre Lureau 2014-06-06 16:02:12 UTC
 $build = $micro << 12 + ($release[0] << 4 + $release[1])

With this scheme, we have limitation of:
- 16 max micro version numbers
- 256 release
- 16 -z releases

Imho, a better way would be to simplify upstream version scheme.

0.5.6 could be v5, 0.6.0 could nicely become v6.

In other word, there are no clear meaning currently for the version scheme, but it cases a lot of trouble for windows version.

Comment 3 Marc-Andre Lureau 2014-06-06 16:04:43 UTC
Adding Daniel in Cc

Comment 4 Marc-Andre Lureau 2014-06-06 16:28:12 UTC
patch for

With that, the spec will need to be updated to compute buildid=(%release[0] << 4 %release[1])

Comment 5 Daniel Berrange 2014-06-09 11:52:12 UTC
Posted a patch upstream to reduce virt-viewer versions to just major.minor instead of major.minor.micro, and bump version to 1.0. This will make it easy for us to translate z-stream release numbers into the $buildid field once RHEL rebases to 1.0 release.

For our existing RHEL builds using older version scheme (ie 0.5.6  / 0.6.0) we'd have to do some short-term RHEL specific hack to munge $buildid in some manner.

Comment 7 Julie 2015-01-27 06:12:59 UTC
(In reply to Marc-Andre Lureau from comment #1)
> To simplify a bit, -z releases version upgrade are quite broken. In general,
> customer will have to perform uninstall first to make sure to use the next
> release...

Hi Marc,
   For future bugs that does not require doc text, pls set the 'requres_doc_text' flag to '-'. I have removed the doc text for this bug and set the flag to -.


Comment 9 errata-xmlrpc 2015-02-11 17:44:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.