[virt-tools-list] VirtViewer version scheme and Windows ProductVersion

[Daniel P. Berrange]

On Thu, Jul 25, 2013 at 08:14:16PM +0200, Marc-André Lureau wrote:
> Hi
> 
> First of all, I am not a Windows Installer expert, and I would prefer
> to follow good practices rather than weird workarounds.
> 
> On Thu, Jul 25, 2013 at 7:56 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> > On Thu, Jul 25, 2013 at 07:36:16PM +0200, Marc-André Lureau wrote:
> >> Hi,
> >>
> >> The Windows Installer requires a ProductVersion of major.minor.build
> >> to perform update correctly. The fourth field is ignored.
> >> (http://msdn.microsoft.com/en-us/library/windows/desktop/aa370859%28v=vs.85%29.aspx)
> >>
> >> What is the current version scheme meaning? Could we switch to
> >> something that would fit Windows? It seems to me major.minor.build
> >> would fit better, especially for downstream windows distro who may
> >> want to maintain their own build (ovirt/rhevm). The leading 0 could be
> >> dropped, so  what about moving form 0.5.6 to 1.0 or 5.7
> >
> > I don't see any need to change what we do for our versioning
> > scheme.
> >
> > The ProductVersion is 3 digits and that can easily map directly to
> > our existing 3 digit release numbers. If you need todo multiple
> > rebuilds of the Windows installer for the same version, that doc
> > above describes something called a "package code" which could be
> > incremented for each new build.
> 
> I would like to know what is the purpose of the leading 0.

It is simply part of the version number,  (major, minor, micro).
That it is zero simply means I've not considered us to be at
version 1.0.0 yet. It doesn't indicate that the leading 0 is
unused.

> >
> > Alteratively, the build number field of the ProductVersion is
> > allowed to take values in the range  1-65536. We never use that
> > whole range for micro version numbers. So we could use that to
> > encode the micro version number + build number by shifting the
> > micro version number 8 bits.
> 
> >
> > eg,
> >
> >   version     build    productversion
> >   0.5.6       0        0.5.1536   (6 * 256 + 0 == 1536)
> >   0.5.6       1        0.5.1537   (6 * 256 + 1 == 1537)
> >   0.5.6       2        0.5.1538    ...
> >   0.5.7       0        0.5.1792
> >   0.5.7       1        0.5.1793
> >
> 
> Eh ok, that will cause some confusion but can do with that, if the
> leading 0 is so important.
> 
> > If ovirt/rhevm want todo their own custom windows installers then
> > IMHO they should be using a different package name and/or ProductCode
> > to distinguish their builds from the official builds.
> 
> The product code is a uuid, and we already use that.
> 
> We could use a different package name and version scheme, but then we
> probably want to use different path etc. That will make it harder to
> switch between one and the other I suppose.

Well I'd really recommend that as a community project, ovirt shouldn't
build custom installers, instead use the official one we provide. I
understand if RHEV wants to build an installer, as part of its product,
but then I don't see that a productized installer is something we need
to care about as upstream from the POV of upgrade paths, and I'd really
expect them to use a different name too "rhev-virt-viewer" or something
to indicate that its a productized branch.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|