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

[Marc-André Lureau]

----- Mensaje original -----
> On Fri, Jul 26, 2013 at 07:31:34AM -0400, Marc-André Lureau wrote:
> > Hi
> > 
> > ----- Mensaje original -----
> > > > What is the difference between "minor" and "micro" in your naming? How
> > > > can it be decided or interpreted between one or the other? It is worth
> > > > to have some clear rule for versioning.
> > > 
> > > micro is intended for releases that are mostly bugfixing, minor for
> > > releases introducing non-trivial new features, major for large new
> > > features or changes which are disruptive to user experiance
> > 
> > We haven't been following this practice closely in the 0.5.X releases.
> > 
> > Your definition of micro seems like it should be a stable branch of the
> > major.minor. That would indeed make sense, if only we were doing it.
> 
> No, a stable branch would add a fourth digit.

The problem with your definition of .micro is the "mostly". What should go in minor or what should go in micro is subject to debate. That's something we can avoid.

> 
> > > > > > Well, upstream would have the same issue if it would have a
> > > > > > "stable"
> > > > > > release of some sort.
> > > > 
> > > > You drop the possibility to make stable windows installer releases
> > > > upstream?
> > > > 
> > > > Or you would implement the 8 bit shifting of "minor" in the
> > > > productversion
> > > > "build" field?
> > > 
> > > I don't think this drops that ability at all. There is plenty of scope
> > > in the windows version numbers to encode even a 4 digit version number
> > > and a build number.  The micro numbers rarely go above 10, if we had
> > > a stable branch that'd be pretty unlikely to go above 10 in numbers
> > > so you could easily encode those two digits into one byte, leaving a
> > > second byte for the build number
> > 
> > Given that we are already talking about 0.5.7, I would say we get
> > close to 10 pretty easily.
> 
> This discussion is pointless bikeshedding. It is perfectly possible to
> do windows installers with the versioning scheme we already have. I see
> no reason to justify changing
> 

It's not useless since we have a problem with windows installer updates and our version scheme.

Please believe me, I have no fun at all, and I would prefer not to have to deal with those Windows issues and get rid of this problem quickly. But between using a weird windows version scheme that doesn't follow upstream and getting a clear understanding for the version scheme we use, I prefer the later.