On 9/5/05, D. Richard Hipp <[EMAIL PROTECTED]> wrote: > On Mon, 2005-09-05 at 10:57 -0500, Ian Monroe wrote: > > I do not see how such a major change can be justified in a minor point > > release. For instance, currently amaroK does not work when using a > > sqlite database on Debian Sid since they package it with sqlite 3.2.5. > > > > Shouldn't this have waited for 4.0? > > > > There are no plans at this time to ever release version 4.0. > > SQLite has *never* supported the ability of a handle to be used > by more than one thread. By luck, such use would sometimes work on > some operating systems. But it would fail on others. Such a > situation is very dangerous since if a developer is working on > a system where the misuse of SQLite just happened to work, they > might not detect their design error and then ship non-working code > to a customer where it would fail. A minor change in check-in [2517] > detects the misuse of SQLite on all systems and prevents it from > working even by chance. This allows the problem to be detected > early and corrected before it reaches a customer.
But it has already reached our users. amaroK has never had a reported problem with this. In this case "early" is a year or so too late. What about an --incorrect-behavior configuration option? Or a warning to stderr instead? > This is not a design change. This is not an API change. > It does not break backwards compatibility. Um, yes it does. amaroK works with one version of sqlite but not the next. What is the actual definition of backwards compatable? This reminds me of the scene in Office Space where they lay off Milton by "correcting" the accounting error that lead to him continuing to get his checks. :P > All that changed > is that certain errors in the way SQLite is used are now > detected sooner rather than later. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > >
