Richard Frith-Macdonald wrote: > On 20 May 2009, at 23:17, Yavor Doganov wrote: > > I am counting only the major releases when there was a soname > > bump; the regular point releases are not interesting for this > > discussion. > > Then the discussion seems rather pointless ... since what you are > calling the 'major' releases are those were we make ABI changes and > bump the soname.
Well, no matter how they're called, that's the core of the dispute: whether actually there's an ABI break that warrants the soname bump. If there is a real ABI break -- that's OK, but it if it's just the feeling "We've accumulated a pile of big changes, so we might be breaking the ABI; let's force recompilation for extra safety" -- that's a problem. > the chances are that any individual ABI change will not break your > application because the app will not be using the feature concerned. Most probably that's the reason why some people (myself included) think that some of the soname bumps are unwarranted. I quickly looked at the diff between two adjacent releases when the latter claimed to be "binary incompatible", and surprise -- it really is. There is at least one ABI-breaking change which implies a SONAME bump. I don't have the time to check every pair of recent (>=1.13 for Base) releases so far, but I'll do it from now on, and I am much more confident that you're doing the right thing. > Chasing MacOS-X is a problem for us I realize this, and I understand that it's hard enough even if one does not count the various library maintenance issues. I am not blaming, and will never blame, for breaking the API or ABI, being intentional or not. You are all doing an exceptionally wonderful job, no matter what. > Yes, with the manpower they have (and perhaps more importantly, the > fact that they control the entire operating system) it's relatively > easy to add runtime tricks to pick the behaviors they want. I wholeheartedly agree here. Also, if I may add, judging by the large piles of code-bases that were made free software through the years, such approaches are (although smart in some situations) an unportable mess which has to be rewritten/redesigned some day. Only the GNU architectures are about 20, with 3 different kernels (and GNU/kOpenSolaris coming along soon). Add here the free *BSD family systems, the proprietary Unices, Windoze, etc... GNUstep supports most (if not all of them, to some extent at least), and that's an enormous effort and achievement already. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
