On 11 Jan 2011, at 12:15, Richard Hipp wrote: > That new OS release includes the latest shared library for > SQLite.
You didn't put it there, and the consequences of putting it there are not your responsibility. Nor are the consequences of someone else's app breaking because they didn't read the docs and coded to observed behaviour instead of specified behaviour. Why does the vendor of this OS release not ship multiple versions of SQLite so that apps coded to bind to 3.7.4 get 3.7.4 and apps bound to 3.6.23.1 get 3.6.23.1 and so forth for all previous versions they have shipped? This is pretty basic dynamic linking functionality that exists on all modern platforms. > Sure, the problem really is that the apps were incorrectly > coded. But does your mom really care about that? They worked before. This situation, or analogous ones, crop up any time you're supplying a product with a documented API and design when you have shipped a version which did not do exactly what that design specifies and later wish to correct it. The two extremes of responses are: 1) We noticed a bug in that we weren't enforcing the documented API. We have now fixed it. If your app was relying on the previous faulty behaviour you will need to rectify it. Remember that the API as documented is what you should code to and not the current behaviour which may (due to human error) deviate from the spec at any given point in time and therefore may be subject to revision to correct it. If you observe such a deviation please report it to us so that it can be fixed. 2) We will never change the external behaviour of our product. Path (2) realistically means you never change anything, never add a new feature, never fix any bug, in case someone is reliant on it. Path (1) will annoy people from time-to-time but it leaves people knowing where they stand. As a developer-customer I prefer (1). I don't want to have to test that the code does what it is documented to do all the time, I want to read the docs and code to that, and to know that if I find a discrepancy between the documented and observed behaviour that I can report a bug and you will (probably, if it will affecting more than just my code or I pay you) fix it, or accept a patch to fix it. Best Regards, Phil Willoughby -- Managing Director, StrawberryCat Limited StrawberryCat Limited is registered in England and Wales with Company No. 7234809. The registered office address of StrawberryCat Limited is: 107 Morgan Le Fay Drive Eastleigh SO53 4JH _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
