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 _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
