On 20 May 2009, at 11:53, Yavor Doganov wrote:
On Wed, May 20, 2009 at 11:24:39AM +0100, Richard Frith-Macdonald
wrote:
I think what you are describing (as the correct way to do things) is
what GNUstep already tries to do ... see
http://mediawiki.gnustep.org/index.php/GNUstep_release_policy for the
actual release policy details.
On the contrary -- this very policy is the problem.
The SONAME of a shared library should be bumped if and only if there
is
ABI break, not because of publicity reasons, big API additions, or
anything else. You can continue to version stable releases with even
numbers and unstable releases with odd numbers and release them in any
order you feel apropriate; the SONAME has absolutely nothing to do
with
the package version.
In fact, this link appears to directly contradict itself:
The library (SONAME) versions is changed when the major or minor
version number of a release changes, but not the subminor number.
and
The minor version number is changed (and therefore the library
version) when we break backward compatibility
This does not appear to be what really happens. The minor version
number is changed with each new release. This causes installed
applications to link against the old GNUstep if you leave it installed
(or to just fail if you don't) and causes linker problems with
frameworks, since they will link against the GNUstep that they were
compiled against while apps that link against them will also link
against the new GNUstep.
How you version the releases and what is considered
"stable" and "unstable" is completely orthogonal to the library
versioning.
is technically true, it's not what people expect in practice, and
therefor not policy. The policy is to keep the main so version
numbers
in sync with the main release version numbers, because that matches
normal expectations.
Name just one library -- just one -- on your GNU system that behaves
this way. Consider what would happen if glibc or glib/gtk+ bump the
soname every six months... I find it incredibly hard to believe that
this is "normal expectation".
Totally agree. For a great many packages (and for OS X frameworks)
the soname is completely unrelated to the library version. If you
need to know the installed library version, you ask your package
manager or pkg-config, or you read some global value / call some
global function.
However, I don't think there have been any recent releases which
should
have changed the so number for any of the libraries.
I've made an experiment some time ago by altering the symlinks without
recompiling anything. Every GNUstep app in Debian worked out of the
box
(of course that's not a 100% proof that the new Base/GUI were ABI
compatible).
Exactly the same for me on FreeBSD. We're not actually breaking the
ABI, we just look to the linker / loader like we are doing, which is
even worse because it has the same effect while being trivially fixable.
David
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
