Hi, Thierry Vignaud <tvignaud@xxxxxxxxxxxxxxxx> writes: > but there's also the problem that currently we also have to rebuild > dependant packages on each gimp release because major bumped on each > release (since lib major equals version number's minor) even if there > really wasn't any api change. > > i usually advocate the "let bump the major lib" on api/abi change > because it enable to track common problems: As I said already (and this is certainly the last time I am repeating myself on this), we do exactly this. During a development cycle, each and every release is incompatible with the former release, that's why interface_age and binary_age are always reset to 0. > i agree that you way works too and i agree the packaging issues may > not be strong enough so that you alter gimp library versionning > system. We use the same versioning scheme as almost all of the libaries we depend on. That alone is a strong argument to stick with it. > note that you approach results in having several libgimp1.3.XYZ libs > installed at the same time when one update whereas there were no real > api change (easily "fixable" of course but ...). I doubt that you can find a release in the 1.3 cycle that is API and ABI compatible with another release from the 1.3 cycle. I have to admit that we don't go thru the hassle of checking this for each release but simply follow the policy of assuming that the API has changed. But I am pretty sure that it did indeed change for every or at least almost every 1.3 release. Sven
