[SCM] Samba Shared Repository - branch master updated - release-4-0-0alpha8-154-g826ee30

Jeremy Allison jra at samba.org
Thu Jul 2 15:32:46 GMT 2009

On Thu, Jul 02, 2009 at 01:52:48PM +1000, tridge at samba.org wrote:

> why don't we want a new version? It has new functionality, it has bug
> fixes, and it has a different ABI. Why doesn't that justify changing
> the soname version? What is the criterion for changing the number if
> not that?

As Simo pointed out, there are issues when two different
versions of the same library get loaded into the same address
space. Moving to a new major version is something library
maintainers usually avoid if they can, for this reason. If this were a
major change (for some unknown value of major :-), then I'd
agree we need talloc.so.2, but we have a compatibility workaround
that seems to make this a gratuitous change.

If there were no other way to do this I'd agree with you,
but there are backwards compatible ways to do this, so why
not use them ?

> talloc2 would be a totally new package. talloc.so.2 is a soname
> change. There is a world of difference between the two.

Sorry, typo - missing "." :-).

> I have never noticed any teeth gnashing over the doom of free software
> because some library changed its version number, except in this email
> thread.

It's a matter of consideration to our external users, many
of whom we may not know. I don't want us to get a reputation
of *gratuitously* changing major version numbers, as this can
cause problems. If we have a workaround to keep the binary
ABI, I don't see why we're not using it. If there were no
workaround then of course we'd bump the major .so and tell
people we had no other choice - which would be the correct
thing to do.


More information about the samba-technical mailing list