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

[Marc-André Lureau]

Hi

----- Mensaje original -----
> On Fri, Jul 26, 2013 at 07:42:45AM -0400, Marc-André Lureau wrote:
> > 
> > 
> > ----- 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.
> 
> No, choice of how to increment version numbers is always a subjective
> decision. You can never get something black & white. That's why my
> description allows for flexibility of interpretation there.

It allows for confusion, since distinction between minor and micro are fuzzy. I don't understand why we have minor and micro, none of which indicate anything particularly meaningful. At least if micro would indicate stable releases, that would be useful.

> > > 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.
> 
> Such is life with Windows. It defines an unreasonably restrictive
> version scheme that I have no desire to have ourselves follow.

that's being very helpful!

I guess I'll have to implement the suggestion you made in your first reply...

I'll put in ProductVersion buildid = micro << 8 + buildid

cheers