There's the issue of "this is what I meant" vs. "this is what I did." When you have a couple hundred customer's, changing the code is painful but doable. When you have a couple million customer's, then what is "out there" is the "true" API and must be kept around. Microsoft has bent over backwards to keep old bugs around because of major applications taking advantage of undocumented behavior.
When MS made the decision to break with backwards compatibility in favor of security and forward progress they introduced Vista and the world hated it. -Scott sqlite-users-boun...@sqlite.org wrote on 01/11/2011 07:57:13 AM: > > 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
