Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48787 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 51116 invoked from network); 15 Jun 2010 14:01:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jun 2010 14:01:45 -0000 Authentication-Results: pb1.pair.com smtp.mail=ilia@prohost.org; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=ilia@prohost.org; sender-id=unknown Received-SPF: error (pb1.pair.com: domain prohost.org from 209.85.212.42 cause and error) X-PHP-List-Original-Sender: ilia@prohost.org X-Host-Fingerprint: 209.85.212.42 mail-vw0-f42.google.com Received: from [209.85.212.42] ([209.85.212.42:39255] helo=mail-vw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 77/70-47853-7C7871C4 for ; Tue, 15 Jun 2010 10:01:44 -0400 Received: by vws2 with SMTP id 2so2114648vws.29 for ; Tue, 15 Jun 2010 07:01:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.198 with SMTP id v6mr4036892vcr.179.1276610501172; Tue, 15 Jun 2010 07:01:41 -0700 (PDT) Received: by 10.220.70.202 with HTTP; Tue, 15 Jun 2010 07:01:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Jun 2010 10:01:41 -0400 Message-ID: To: Adam Harvey Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary=0016e6d2755a705fe40489120bbd Subject: Re: [PHP-DEV] Remove sqlite2 from trunk From: ilia@prohost.org (Ilia Alshanetsky) --0016e6d2755a705fe40489120bbd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Just to clarify, removal does not mean deletion, it would simply become a PECL extension people who need it can still use. On Tue, Jun 15, 2010 at 9:30 AM, Adam Harvey wrote: > On 15 June 2010 19:41, Ilia Alshanetsky wrote: > > After speaking to a few developers in DPC, I think it makes sense for u= s > to > > drop the Sqlite2 extensions from Trunk as they are superseded by the > Sqlite3 > > extensions. The sqlite2 library is no longer maintainer and the migrati= on > > path from version 2 to 3 is very simple. Unless there any objections, I= 'd > > like to make this happen in the next week or two. > > Funnily enough, we had a short discussion about this on IRC last week; > I was meaning to write an RFC before getting swamped at work. My > feeling (and I'm speaking just for myself here) is that we can't > really get rid of ext/sqlite in the short to medium term: people have > gotten too used to having it available and bundled in a default PHP > installation. Obviously, though, we can't really keep bundling an > unmaintained library, either, and we should start nudging people > gently towards sqlite3. > > What I'd prefer: > > =96 Deprecate ext/sqlite in trunk, at least by having sqlite_open() > generate an E_DEPRECATED warning. > =96 Unbundle libsqlite2 in the next major version after what's currently > in trunk and disable the extension by default, but still allow > compilation against an external libsqlite2 if the user really wants > to. > =96 Move ext/sqlite to PECL at some point thereafter. > > PDO would be handled similarly. > > If someone has some real world numbers on the use of ext/sqlite, that > might be handy. From where I sit, though, it does seem to have become > a bit of a standard, so I'd rather not pull the rug out from under > people that suddenly =97 particularly given it's not even deprecated at > the moment. > > Adam > --0016e6d2755a705fe40489120bbd--