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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev