Re: gnustep release numbers

[Richard Frith-Macdonald]

On 5 Oct 2006, at 00:01, Helge Hess wrote:

> On Oct 5, 2006, at 24:30, Hubert Chan wrote:
> Thats because the program you check only uses the "old" API. ABI  
> compatibility is _exact_. You can't add a (public) class or method  
> and you must not "fix"(/change) the behaviour in an incompatible way.
> Eg if gnustep-base 1.13.0 adds NSOutputStream and a tool uses that  
> it can't be ABI compatible with 1.10.0 for obvious reasons.
>
> So keeping a stable ABI bites with advancing gnustep-base which is  
> often work for adding additional Cocoa methods, classes or fixing  
> incompatible behaviours etc.
> Which is why I _encourage_ having more GNUstep _alpha_ releases to  
> move things forward quickly in the release-early-release-often  
> spirit. But at the same time its not really hard to keep _one_  
> maintained and published "guaranteed" state a "thirdparty"  
> developer can rely on.

Ah .... I finally see what you are getting at.

You want a single 'stable' release that everyone is expected to code  
to and where they can expect (for a few years at least) to be able to  
expect their binaries to run when they supply them to a third party  
because they expect that third parties will have that release  
installed on their system.

That's easy for frozen/dead systems, but hard for living, changing ones.

Any release would do as 'stable' for this purpose ... but only if no  
other releases were made after it for a long time ... since  
regardless of what you say about stable/unstable, people like to have  
new features etc (in the case of GNUstep there is a strong desire for  
MacOS-X changes to be incorporated for instance) and will, if you  
make 'unstable' releases with significant new features , want to  
download and install the 'unstable' release.

If I seem incredibly slow in understanding what you mean by 'stable',  
please understand that it's just that the idea of trying to enforce a  
frozen ABI for years seems utterly impractical.  Even for gnustep- 
base it would not be easy (the drive to MacOS-X compatibility is too  
strong), but for other less complete parts of the system and the  
system as a whole there is really no chance of such a freeze.  We  
would probably have to make the subversion repository private to  
prevent 'unstable' versions getting out.  I think such a freeze would  
kill GNUstep.