On Friday 26 November 2004 18:51, Sean Middleditch <elanthis@xxxxxxxxxxxxxxx> wrote: > > > so by that argument, if gtk had an api break then mozilla should work > > > around it, rather than making the fix occur in gtk? > > > > Yes. That's how things work in real world. > > No. No, it is not. In the toy development system world, maybe. In the > real world, major system libraries like GTK and Python remain ABI and > API stable. If a breakage does occur, the breakage is separated into a > new major version allowing both versions to be installed. GTK in fact > makes that guarantee, and that is one of its biggest selling points. In what world are APIs really stable? Some people who use an OS other than Linux have problems with shared object versions where several applications from the same vendor ship different versions of the same shared object that conflict. On that OS you were required (last time I programmed for it - which was fortunately a while ago) to rename the libc shared object if you wanted to have it dynamically linked into your applications. This meant that several applications from different vendors would have different versions of the libc which all came from the OS vendor! In the Linux world we are way better than that! > > As a developer you spend a significant time to work around bugs, API > > changes and things which don't behave as you expect them to do. > > That's not an excuse. That's a description of all that's wrong with the > world from a programmer's perspective. ;-) Bugs are going to happen, > but there is absolutely *no* reason for an API/ABI breakage, ever, > without at least versioning the break correctly. The real issue is, given that the API has broken and systems have broken as a result, what shall we do about it? Beta testers are very valuable. We don't want to burn them so badly that they give up testing! If we have to release a hacked-up version of an application to allow recovery from a broken ABI as an interim measure then that's not a problem IMHO. I think that the priority in this situation should be to get the testers' systems running properly again ASAP so that they can continue testing. There are probably already bugs in rawhide packages going undiscovered because the most dedicated testers have broken systems that can't be upgraded! -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
