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