>This is, technically, a compatibility break. On the other hand, there >appear to be vast numbers of smartphone applications that currently depend >on undefined behavior and will suddenly stop working if we don't make this >change.
I understand the proposed change will have no incidence for correctly written application but as a principle, I really can't agree with the idea of changing an engine core for the benefit of poorly written apps disseminated in the wild. My rationale is that either it's technically or economically feasible for the offending applications' developpers to change their code to use the library correctly (and that doesn't seem to be the case), OR very simply avoid upgrading to the new SQLite versions. I don't get what good reason they had to switch to new SQLite versions. Any basic app testing would have revealed incompatibility before they upgrade to newer SQLite, so they knew about the issue. It makes full sense that if a third-party library evolves, which changes break your own bad code, then you keep on using the old version without asking the library author to take extra steps backward to cope with your own incompetence. That's specially true when the said library is free beer. Since that market share (smartphones) managed to upgrade the smartphones in use with the new SQLite version, how can we understand that they can't upgrade their apps as well using a conforming API use? Now if for some weird reason they can change SQLite lib but can't upgrade the offending apps in the field, they can still either downgrade to the latest SQLite version which works for them or (and they all have enough resource for doing so) fork their own private SQLite source from the current version and apply any change they want/need, without bragging over the rest of the community. All this doesn't make any sense to me. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
