tentative 5.3 release plan

hi Lars, Johannes, Lukas,

Hi Lars,

2008/7/13 Lars Strojny lars@strojny.net:

Hi Lukas, hi Johannes,

Am Freitag, den 11.07.2008, 11:59 +0200 schrieb Lukas Kahwe Smith:

• MySQLnd

what's with PDO MySQLnd, will it be part of 5.3?

It is the case already. All MySql extension uses ext/mysqlnd by
default (at least on windows ;).

So I was wrong.

It is not yet in. I really wonder why it is not developed in php's
repository directly. As it can build against both libmysql and
mysqlnd, it can have no impact on the existing code until it is
stable.

Also, reading the 5.3 todos:

Patch PDO_MYSQL to optionally support mysqlnd library in addition to the MySQL client library,

Please note that we will not use libmysql anymore on Windows from 5.3+.

Correct me if I'm wrong but was It the plan since the introduction of
MySqlnd to completly drop libmysql so mysql can continue his stuff on
the gpl/commercial side without bother with PHP (translation of the
"gift to the PHP community" :).

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

Lars Strojny schrieb:

Hi Lukas, hi Johannes,
Am Freitag, den 11.07.2008, 11:59 +0200 schrieb Lukas Kahwe Smith:

• MySQLnd
  what's with PDO MySQLnd, will it be part of 5.3?

We did a tough development sprint in the last weeks to make the
patch "ready" for the tentative PHP 5.3 release plan. Our internal
release plan shows no coding between Beta and GA but fixing newly
reported bugs. All coding was planned to be done by the release of a
beta - we have reached some 80% of the beta goals.

I expect Dmitry to bail out about PDO_MYSQLND quality and
performance. Dmitry/Zend is doing some excellent QA behind the
scenes. But I do not expect any user to complain about us delaying a
PHP 5.3 release by checking in unstable and buggy code. The patch
(PDO_MYSQLND) won't break PDO_MYSQL anymore if it goes into the PHP
CVS.

Johannes is working on a 3-stars change (***zval) to both PDO and
PDO_MYSQLND which I would like to test first before the patch
(PDO_MYSQLND) goes into the PHP 5.3 CVS. That's days, not weeks,
just enough time to see people discuss the tentative PHP 5.3 release
plan and the PDO_MYSQLND entry on it.

The patch should be in CVS by July 24th.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

Ulf Wendel wrote:

We did a tough development sprint in the last weeks to make the patch
"ready" for the tentative PHP 5.3 release plan. Our internal release
plan shows no coding between Beta and GA but fixing newly reported bugs.

What about the already reported (a.k.a. "old") bugs? :)

--Jani

hi,

The PDO_MYSQLND extension, as I call it, is a patched PDO_MYSQL extension.
PDO_MYSQLND is on the TODO list [1].

Yes, why this point has been raised here.

I hardly ever blogged about PDO_MYSQLND as a patch, although it is more of a
patch than a new extension. PDO_MYSQLND reads shorter than a lengthy rather
technical explanation.

As blogging is all nice and shiny, php-internals are the place to
discuss internals issues. There is also a PDO dedicated list.

However, at some point we "forked" PDO_MYSQL and started to patch it to
optionally support mysqlnd. This was the easiest way to add mysqlnd support
to the PDO MySQL driver (PDO_MYSQL). PDO_MYSQL was the last MySQL extension
in row to be upgraded to support both mysqlnd and the MySQL Client library
(AKA libmysql). ext/mysql and ext/mysqli can already be compiled against the
MySQL Client library, like ever since (= 100% BC), or be compiled against
mysqlnd.

Thanks for that, and mysqlnd is used or will be used by default on our
windows releases/snaps.

Early versions of the patch did have a very poor quality. By "poor" I mean
"poor" - like 60% of the tests crashing. Things became better in April
(MySQL UC, alpha release). But the April version was still not good enough
to be checked into the PHP 5.3 CVS repository. It was clear that it would
take several more months to get the job done with the resources assigned to
it.

Well, if you have resources issues, it is even another good reason to
do not "hide" your development in some mysql's site. It is amazing how
helpful the PHP developers can be while hunting bugs or improving
things. And mySQLnd is a PHP.net software no?

From the mysqlnd development we know that only very few PHP users are
interested in bloody steaks. So, why should bad boy MySQL break the php.net
PHP 5.3 repository and mess up PDO_MYSQL for months instead of stabilizing
the patch first? In particular if there is no pressing reason...

As you cernainly noticed already, there is one pressing reason, the
freeze of PHP 5.3 will happen in 9 days. As it can be built against
libmysql or mysqlnd, why not leave libmysql as defult until it reached
an usable state? Please note that usable does not stable nor beta.

The other reason is to let us see how it works, to test it smoothly
while testing any other part of the core PHP.

Those who want alpha code can get it from us at any time.

I could get it at any time with PHP if it was in PHP's cvs.

We did a tough development sprint in the last weeks to make the patch
"ready" for the tentative PHP 5.3 release plan. Our internal release plan
shows no coding between Beta and GA but fixing newly reported bugs. All
coding was planned to be done by the release of a beta - we have reached
some 80% of the beta goals.

The freeze and the release following it is not beta but alpha. That
hences the reason of our questions. If you reached 80% of the beta
goals, why don't you commit it now?

I expect Dmitry to bail out about PDO_MYSQLND quality and performance.
Dmitry/Zend is doing some excellent QA behind the scenes. But I do not
expect any user to complain about us delaying a PHP 5.3 release by checking
in unstable and buggy code. The patch (PDO_MYSQLND) won't break PDO_MYSQL
anymore if it goes into the PHP CVS.

The goal of the release phases is to test. If myslqnd happens to be
broken and it is not possible to fix it in time for 5.3, it will be
dropped or disabled by default. I think that how we worked in every
single PHP release (more or less). The more you wait until a commit,
the harder it will be for us to test, valid and help you to improve
it.

Anyway, it is too late to change your way of working with php.net (at
least for the 24th).

Good luck for the next days ;-)

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

Lukas Kahwe Smith wrote:

Lukas Kahwe Smith wrote:

In our dreams someone would also make PDO a focus area, since the
number
of open bugs is getting ridiculous. This is also a call to the general
community to try and help to find a PDO maintainer. In the mean time
people not adapt in C might at least try and plow through the bug
tickets to find duplicates and verify the open tickets, write tests
etc.

For PHP 5.3 on, I'd be happy to see the Windows builds of PDO_OCI only
produce php_pdo_oci.dll and no longer also build php_pdo_oci8.dll.
The latter uses an older set of Oracle client libraries that allows
connections to Oracle 7 and 8.0 databases.

I guess for windows it just comes down to what we bundle.

We could still support older Oracle versions with an optional
download. If we want to be super fancy, we might even include a note
in an error message when trying to connect to older versions that
there is pdo_oci8 available as an optional download from win.php.net
(or whatever our pecl4win.php.net replacement will be).

I'd prefer to keep the status quo instead of making the build more
complex. The idea was to simplify the distribution and move forward.

The DB versions in question are Oracle 7 - released in 1993, and
Oracle 8.0 - released in 1997, IIRC. These versions are even more
uncommon than when PDO_OCI was created in back 2004.

Users of more recent DBs (or on non-Windows platforms) won't be
affected in anyway.

The workaround of building your own PHP on Windows is less of a
problem now there is improved Windows build infrastructure and
documentation.

Chris

--
Christopher Jones, Oracle
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad

Daniel Convissor wrote:

For PHP 5.3 on, I'd be happy to see the Windows builds of PDO_OCI only
produce php_pdo_oci.dll and no longer also build php_pdo_oci8.dll.
The latter uses an older set of Oracle client libraries that allows
connections to Oracle 7 and 8.0 databases.

The impact is that users on Windows will no longer be able to connect
to the older databases unless they compile the extension themselves.

Removing it completely or requring people to build it themselves is
sub-optimal. If you really want it out of PHP, please make it a PECL
package.

The plan is to continue shipping php_pdo_oci.dll. This allows users
to use PDO_OCI to connect to Oracle 8.1, 9.2, 10 and 11 Databases.

The codebase for php_pdo_oci.dll and php_pdo_oci8.dll is the same (and
only one can be enabled at a given time)

Non-windows users of PDO_OCI would be not affected in anyway whatsoever.

Chris

--
Christopher Jones, Oracle
Email: christopher.jones@oracle.com Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad