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 <ahar...@php.net> wrote:

> On 15 June 2010 19:41, Ilia Alshanetsky <i...@prohost.org> wrote:
> > After speaking to a few developers in DPC, I think it makes sense for us
> to
> > drop the Sqlite2 extensions from Trunk as they are superseded by the
> Sqlite3
> > extensions. The sqlite2 library is no longer maintainer and the migration
> > 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:
>
> – Deprecate ext/sqlite in trunk, at least by having sqlite_open()
> generate an E_DEPRECATED warning.
> – 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.
> – 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 — particularly given it's not even deprecated at
> the moment.
>
> Adam
>

Reply via email to