[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnustep release numbers
From: |
Richard Frith-Macdonald |
Subject: |
Re: gnustep release numbers |
Date: |
Thu, 5 Oct 2006 05:46:11 +0100 |
On 4 Oct 2006, at 23:30, Hubert Chan wrote:
Ah ... different issues.
By Helge's definition, the ABI changes with any release which adds/
removes functionality, so all but minor bugfix releases have a new
ABI/SONAME. However, we could release new versions with the same
SONAME but added functionality.
(you never need to recompile programs for a new release if you keep
the old libraries ... that's what library versioning is for).
Actually, with the recent GNUstep 0.11.0/1.13.0 release, you are
unable
to run programs compiled against 0.10.3/1.12.0 because the old library
could not communicate with ... I think it was gdnc (I assume due to a
change in the communication protocol).
Perhaps you are referring to the change to use unix domain sockets
rather than tcp/ip sockets by default? If so, there is a user
defaults setting to control the runtime behavior so you can tell all
apps to use one or the other. This default behavior change was
phased in gradually, with new user defaults added to control the
behavior and documentation updates to warn people about it. There is
no ABI or API change involved here.
On the other hand, if you take a program compiled against
0.10.3/1.12.0
and make libgnustep-base.so.1.12.0 a symlink to
libgnustep-base.so.1.13.0, and libgnustep-gui.so.0.10.3 a symlink to
libgnustep-gui.so.0.11.0, it seems to run perfectly fine. I just
tried
it on my system, with a few different programs, and they all ran fine,
which suggests that we didn't need an SONAME bump.
Possibly not.
AFACT, the general rule that most other library developers follow is
that if you add things to your libraary, you don't need to bump the
SONAME. You only bump the SONAME if you remove things, or do other
changes that remove library symbols (such as replace a function with a
#define macro). So AFAICT, we don't really need to bump the SONAME
for
GNUstep at every release.
... currently the SONAME gets incremented in line with changes in the
version number (which is at least clear/simple) whether backward
compatibility is broken or not. This is in line with Helge's
definition of an ABI change, and I'm not altogether happy with it as
my feeling of SONAME being appropriate for control of backward
compatibility ties in with your understanding.
However, I don't see a clear way ahead ...
1. simply decoupling the SONAME from the release version would
generate confusion.
2. incrementing the minor release number and SONAME is a problem for
package maintainers and means the SONAME changes when older apps
could wquite easily run with the new library.
3. keeping the SONAME linked to minor version number, and making
backward compatible releases with subminor version number changes,
only incrementing the minor number and SONAME when previously
deprecated functionality is removed.
My personal preference is 3, but I know it runs into objections from
two camps :
Helge's camp has complained about making releases with the same
SONAME but added features
Publicists/marketers have complain about lots of releases with only
subminor version number changes.
- Re: gnustep release numbers, (continued)
- Re: gnustep release numbers, Richard Frith-Macdonald, 2006/10/05
- Re: gnustep release numbers, Helge Hess, 2006/10/05
- Re: gnustep release numbers, Dennis Leeuw, 2006/10/05
- Re: gnustep release numbers, Helge Hess, 2006/10/05
- Re: gnustep release numbers, Dennis Leeuw, 2006/10/05
- Re: gnustep release numbers, Philippe C.D. Robert, 2006/10/29
- Re: gnustep release numbers,
Richard Frith-Macdonald <=
- Re: gnustep release numbers, Richard Frith-Macdonald, 2006/10/04
- Re: gnustep release numbers, Helge Hess, 2006/10/04
Re: gnustep release numbers, David Ayers, 2006/10/04
RE: gnustep release numbers, Nicola Pero, 2006/10/04