From: Pete B. <pb...@gm...> - 2010-08-04 09:31:27
|
On 2010.08.04 07:42, Peter Stuge wrote: > 1.0.8-36-ge8d7a89 So 36 is the distance since last dot release, and the part after g the first 32 bits of the commit ID. I think that's a good idea. 2 questions though: - do we really need the g? - since you only have 4 32 bit fields for the Windows versioning, with 3 of them occupied by the version, which of the distance or the (partial) commit ID are you going to use? I think I'd prefer the distance to be there, as it makes it easier for Windows developers to instantly see which DLL is more recent than which (comparing dates *should* work, but dates that cannot always be trusted, and there's no way to tell from a date, or a commit ID for that matter, if there were other releases in between), and I guess if you ask your fellow Windows developers (the ones that seem to be interested in binary releases only), they're likely to tell you the same thing as well, i.e. that a git commit ID in the version string isn't as useful to them as an incremental version sub-minor (or whatever that last field is called). NB: since I already took care of automated .rc versioning in libwdi, you might want to have a look at the bump.sh script I use: http://git.libusb.org/?p=libwdi.git;a=blob;f=bump.sh Basically (when run manually, as I don't bump internal version on all commits), that script increments my distance tag, uses it to populate the sub-minor field of all the rc that use versions, and then commits the whole lot. > git diff master..pbatard gives lots of changes. I think that some of > them are more important than others, and some things may be missing > still. Yeah, there are quite a few more things that need to be integrated by Daniel (once I have submitted a new set of patches, which could take a little while), and I'm going to keep using toggable logging in my tree, regardless of what you guys do, because once you have used that feature, you can't go back. It might change shape according to the logging discussion we had some time ago, but I think that, if we want libusb to be useful to developers, and provide them the best support we can, we need to have the ability to include debug logging and toggle it on the fly (through libusb_set_debug), and especially, the binary libraries we produce should have that feature, so that we can troubleshoot problems without asking developers to recompile libusb. Anyway, toggable logging is extra and will come after the rest of the Windows integration has been dealt with. Regards, /Pete |