It seems that Christmas came early this month. SQLite 3.6.20 was released 2 hours ago, and I committed it into the repository. And so the "last dev release" 1.26_07 can include that, and prod can have it 3-4 days later as you say. -- Darren Duncan

Adam Kennedy wrote:
Righto, so I'm going to roll an official "release candidate" dev
version now, and we code freeze at this point (just docs and test
tweaks allowed between now and final).

I'll let the last dev release cook for 3 or 4 days, then do the prod one.

Adam K

2009/11/4 Kenichi Ishigaki <kishig...@gmail.com>:
OK. Agreed.

Kenichi

On Tue, 03 Nov 2009 21:28:59 -0800, Darren Duncan <dar...@darrenduncan.net> 
wrote:

Kenichi Ishigaki wrote:
Our tests are hardly thorough and complete, and while I tried
to write a test for foreign keys, I was hit by a weird bug
that suggested the internal sqlite3 object and the DBI/DBD::SQLite
handle objects were holding different statuses; the same statement
works fine when issued one by one with do, and fails with consecutive
executes. This may not be a showstopper, but is certainly annoying.
(I haven't added the test yet, thoguh. I don't want it to be disabled
again like the one I added just before 1.26_05).

Anyway, I agree to comment out the pragma to turn off the default
foreign keys support tentatively. But I do insist we should wait
at least for two weeks, until the sqlite team release the next
monthly update.
If you mean we should wait 2 weeks and then issue the 1.27-stable as soon as
SQLite 3.6.20 comes out and include that, for the main reason that this would
include the first batch of fixes (if any) to SQLite itself following its
foreign-keys major update, then that sounds reasonable, so our testers of
foreign keys get those fixes.  Especially relevant if the changes to add foreign
key enforcement might have broken something unrelated to foreign keys.  But we
should wait no longer than 3.6.20 to issue our own stable release.  And our
stable would have foreign keys disabled by default. -- Darren Duncan

_______________________________________________
DBD-SQLite mailing list
DBD-SQLite@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbd-sqlite

Reply via email to