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-viewer	Assignee:	Marc-Andre Lureau <marcandre.lureau>
Status:	CLOSED ERRATA	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	high	Docs Contact:
Priority:	high
Version:	3.5.0	CC:	berrange, cfergeau, gklein, juwu, mkrcmari, rbalakri, yeylon
Target Milestone:	---
Target Release:	3.5.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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:
Embargoed:
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 configure.ac:
https://www.redhat.com/archives/virt-tools-list/2014-June/msg00013.html

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

Comment 5 Daniel Berrangé 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.

  https://www.redhat.com/archives/virt-tools-list/2014-June/msg00025.html

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 -.

Cheers,
Julie

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.

https://rhn.redhat.com/errata/RHSA-2015-0197.html