On 6/16/2011 2:50 PM, Lasse Collin wrote: > About -version-info vs. -version-number: *If* it turns out that all > operating systems supported by Libtool should use a versioning style > that is essentially the same as version_type=linux, could > -version-number become the recommended option to set the library > version?
Oh, please god, no. On windows and cygwin, where (a) symlinks can't be used for DLL resolution, and (b) there is no ld.conf/ld.so to manage versions, we REALLY depend on a sane numbering system, because it gets embedded into both the name of the DLL and its clients. (Remember: unlike the *nix schemes, no redirecting via symbolic links is allowed) > Major:minor:revision is easier to understand than current:revision:age, Major:minor:revision artificially entangles package release numbering with API/ABI changes. Typically when one 'goes up' so does the other, but not always -- and not by the same increment. And what if...your package has two different libraries, and only one of them had an ABI change? > which in practice is (major+minor):revision:minor. ONLY if you slavishly follow the one particular scheme for your package version numbering. I'll point out that linux itself (the kernel) doesn't follow that scheme. Nor does TeX. And what if you increment package $major because your *application* has had a major new functionality addition, AND its command line interface has changed...but the DLL hasn't changed at all? Why should the DLL soname be changed just because one of its clients has a new set of cmdline options? Actually, that particular scheme ('bump major for ABI breaks; bump minor for significant new features, bump micro for bugfixes') is honored more in the breach than actually followed...Many projects appear to (accidentally?) break library ABIs with minorver updates...and sometimes majorver updates don't modify the ABI at all but simply represent a big new feature addition -- or a promotion to 'stable' (**) > Using a scheme that > is easier to understand would hopefully reduce mistakes in library > versioning. No, it just ensures that the version numbers associated with shared libraries will ALSO be infected with marketing-induced version inflation. current:revision:age is VERY simple -- if you bother to read the libtool manual (a tall order, for some project maintainers, I'll grant you). But the key point is, *library* version numbers should be entirely unrelated (*) to the *package* version numbers (**). (*) except in the most vague sense of 'when ones goes up, the other one might go up too. Maybe.' (**) Which is why I was mildly annoyed when xz-5.0-final was published, and included a wholly unnecessary "version bump" from 0:0:0 to 5:0:0. Granted, it helped *me* out because I was already using 1:0:0 on cygwin due to an ABI change in the prereleases. Anyway, my annoyance was only mild, because you had announced that soname plan LONG before the event, so we were well prepared for it. -- Chuck _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool