Re: gnustep release numbers

[Richard Frith-Macdonald]

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.