On Jan 13, 2008, at 11:31 AM, Rich Shepard wrote:
On Sun, 13 Jan 2008, Darren Duncan wrote:
I would think something like that is worthy of a 3.6.0 version
number. Not just a minor version increase that would be more
suitable for minor
changes or bugfixes.
I agree with Darren that massive changes to the core of the
system should
be reflected by a major version increase (to 4.0); at a minimum to
a minor
version increease (to 3.6). A version number change from 3.5.4 to
3.5.5
tells folks that it's a minor bug fix or simple adjustment, not a
wholesale
rewrite of the system's core.
There are no user-visible changes to the interface. The version numbers
in SQLite reflect user-visible changes only.
Well, there is one minor user-visible change. The output of EXPLAIN now
has 7 columns whereas it used to contain only 5. But the output of
EXPLAIN
changes from point release to point release all the time anyway, so I do
not consider this something worth bumping a version number.
I do not expect significant instability with the next release. I
want to gain
some experience with the new software before I recommend it for millions
of deployments. But it should be solid and stable as soon as it is
released.
For that matter, the current code in CVS (which is well into the
conversion
to a register machine) has not been giving any problems. There are
people
on this mailing list (ex: Joe Wilson) who appear to read every line
of every
change that we make to SQLite, within minutes of making them, and
complain
if we so much as misspell a word in a comment. And I haven't heard a
peep
from Joe or anybody else, so I'm thinking the code is still working
correctly
for everybody despite the massive changes that have already gone in.
If you find that the current code in CVS gives problems, or if you see
significant problems emerge as we get closer to releasing 3.5.5, then
maybe we might consider calling it 3.6.0. But I do not anticipate any
serious problems. You should not underestimate the level of detail to
which we test SQLite and the thoroughness of the test suite. Not much
is likely to slip through the cracks.
D. Richard Hipp
[EMAIL PROTECTED]
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
