Thierry Vignaud <[EMAIL PROTECTED]> 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.

Gimp-developer mailing list

Reply via email to