Hello all,
Over the last week we have collected todo/wishlist items for PHP 5.3
[1]. We have tried to get in contact with all the known stakeholders
and we have we have gotten enough information from you all that our
release plan will be more than tentative, but you never know and
common sense always rules over plans.
Again the focus areas we see for the coming weeks related to 5.3 are:
- namespaces
- late static binding
- re2c
- windows support
- minimizing BC support/documentation
Additionally we see the following items as very important:
- intl extension
- phar extension
-
E_DEPRECATED - __callStatic
- Garbage Collection
- MySQLnd
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.
This already lengthy list is no where a complete listing of all the
open items people are hoping to get in. At this point we are calling
for a feature freeze [2] by Thursday July the 24th (I will spare you
all a specification of a specific timezone, again common sense rules).
A week after we plan to release alpha1 (July 31st). From then on we
will try to make alpha, beta and eventually RC's in 2-3 week intervals.
Note that we moved closures into 5.3. We thought long and hard about
this one. This is not the opening of the flood gates of engine feature
additions. The reason why we added it was that we had pretty much
universal letters of support for this patch, that it seems fairly
nonintrusive and that the debates over the feature seem to have
resulted in general agreement on the syntax. More over with a well
documented RFC we feel the chances are fairly good that we will not
have any big nasty surprises. That being said, the second we start
seeing that closures have issues that take away from resources from
the above noted items, we will most likely pull the patch from 5.3.
We are hoping to have a stable release of PHP 5.3 out by between mid
September and mid October.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
[1] http://wiki.php.net/todo/php53
[2] We will consider exceptions on a case by case basis until alpha2.
Though there is little chance we will allow engine feature additions.
So for the most part we will allow only fairly self contained changes
within specific extensions. Let us know ASAP if you still have
something in the pipeline (this includes any item on the todo list),
that you feel you cannot complete until the 24th.
Lukas Kahwe Smith wrote:
Note that we moved closures into 5.3.
Awesome! Too make testing closures in PHP_5_3 easy, the current state of
closures should be merged ASAP from HEAD to the branch. The patch that
in linked from the wiki is out of sync with HEAD AFACIS.
Thanks!
Sebastian
--
Sebastian Bergmann http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
I am sure Dmitry will be happy to help out on that on Monday.
Andi
-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of Sebastian Bergmann
Sent: Saturday, July 12, 2008 7:32 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] tentative 5.3 release planLukas Kahwe Smith wrote:
Note that we moved closures into 5.3.
Awesome! Too make testing closures in PHP_5_3 easy, the current
state of
closures should be merged ASAP from HEAD to the branch. The patch
that
in linked from the wiki is out of sync with HEAD AFACIS.Thanks!
Sebastian--
Sebastian Bergmann
http://sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B
5D69
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?
cu, Lars
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 ;).
Cheers,
Pierre
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
Pierre Joye wrote:
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" :).
Are those of us who can't build our own windows binaries still going to be
forced to have it enabled by default? :(
Perhaps that is another reason for getting my customers over to Linux on the
servers :)
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
Hi Lester,
Am Montag, den 14.07.2008, 07:35 +0100 schrieb Lester Caine:
Perhaps that is another reason for getting my customers over to Linux
on the servers :)
If this is true, we should definitely leave it that way :)
cu, Lars
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Lester,
I wonder if you could enlight us, why you hate ext/mysql?
Do you believe the urban legend that smaller .exe/.dll are loaded faster?
Maybe you have never heard of shared code segments... Every readable
only segment is shared on windows. So there is only one copy of the
.dll/.exe loaded for ALL processes using it...
Stefan Esser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkh6/vkACgkQSuF5XhWr2njBNQCgk+JHAUN7cLDA0oSgmU90bd8r
RJIAn1mCKkEsPHQq6W6Fa++MuQRJ05xa
=J5LW
-----END PGP SIGNATURE
Stefan Esser wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Hello Lester,
I wonder if you could enlight us, why you hate ext/mysql?
Do you believe the urban legend that smaller .exe/.dll are loaded faster?
Maybe you have never heard of shared code segments... Every readable
only segment is shared on windows. So there is only one copy of the
.dll/.exe loaded for ALL processes using it...
I don't use MySQL and I never have.
WHEN I run the installation stuff for bitweaver, the only database available
is Firebird, simply because it's the only active interface, so there are no
problems and no confusion. I don't want other packages running - I don't want
to have to install MySQL so as long as I can SWITCH OFF anything that I don't
need on the server I don't have a problem.
The problem comes when you run phpinfo() and it is cluttered with things that
are simply not being used.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
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?
The PDO_MYSQLND extension, as I call it, is a patched PDO_MYSQL
extension. PDO_MYSQLND is on the TODO list [1].
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.
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.
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.
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... Those who want alpha code can get it from us at any time.
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.
Ulf
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
Lukas Kahwe Smith schrieb:
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?
[snip]
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.
It will be ready. I even dared to take a few vacation days last week...
Ulf
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
Jani Taskinen schrieb:
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? :)
Have a look at the bug overview at http://blog.ulf-wendel.de/?p=190 .
Many old PDO_MYSQL bugs have been fixed. I don't claim the list to be
complete. If you are worried about any particular bug, let me know.
A good number of reported bugs are PDO bugs not driver bugs. For example
the LIMIT issue is reported frequently as a PDO_MYSQL bug although it
is a side-effect of the PDO SQL parser [1].
Several new bugs have been found in PDO_MYSQL and PDO. We have not
worked on the PDO bugs as we have focussed on our driver first. Ilia
fixed some of the major ones. Other bug reports are about minor issues.
The thingie Johannes is working on is teaching PDO not to copy zvals
from the drivers but supporting drivers who want to manage zvals
themself, such as mysqlnd does. This change will prevent that we run
into another issue where mysqlnd and PDO logic clash and PDO rejects a
number and returns NULL instead of the number - the only show stopper I
know of. All other issues I see are rather minor ones.
Cross platform testing has been performed on:
AIX 5.3 ppc64
FC4 x86
FreeBSD 6 x86, x86_64
HP UX 11.23 ia64
MacOS X 10.4 ppc32, x86
RHEL 3 ia64, x86, x86_64
RHEL 4 ia64, x86, x86_64
SLES 9 ia64, x86, x86_64
Suse 10.3 x86, x86_64
Win32
Solaris 8 to 10 failed to compile SPL with (Sun) CC last wednesday. I
haven't looked into it yet. Win64 is missing. Anyway, the first
X-platform results are very good, given that I haven't "tuned" the tests
for x-platform compatibility yet.
Ulf
Well, connection issues using mysqlnd seems to be pretty commonly
reported, like this:
There are 20 open reports currently:
I don't know if these are on some list in some blog, I only check the
php bug system for open issues.
--Jani
Ulf Wendel wrote:
Jani Taskinen schrieb:
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? :)
Have a look at the bug overview at http://blog.ulf-wendel.de/?p=190 .
Many old PDO_MYSQL bugs have been fixed. I don't claim the list to be
complete. If you are worried about any particular bug, let me know.A good number of reported bugs are PDO bugs not driver bugs. For example
the LIMIT issue is reported frequently as a PDO_MYSQL bug although it
is a side-effect of the PDO SQL parser [1].Several new bugs have been found in PDO_MYSQL and PDO. We have not
worked on the PDO bugs as we have focussed on our driver first. Ilia
fixed some of the major ones. Other bug reports are about minor issues.The thingie Johannes is working on is teaching PDO not to copy zvals
from the drivers but supporting drivers who want to manage zvals
themself, such as mysqlnd does. This change will prevent that we run
into another issue where mysqlnd and PDO logic clash and PDO rejects a
number and returnsNULLinstead of the number - the only show stopper I
know of. All other issues I see are rather minor ones.Cross platform testing has been performed on:
AIX 5.3 ppc64
FC4 x86
FreeBSD 6 x86, x86_64
HP UX 11.23 ia64
MacOS X 10.4 ppc32, x86
RHEL 3 ia64, x86, x86_64
RHEL 4 ia64, x86, x86_64
SLES 9 ia64, x86, x86_64
Suse 10.3 x86, x86_64
Win32Solaris 8 to 10 failed to compile SPL with (Sun) CC last wednesday. I
haven't looked into it yet. Win64 is missing. Anyway, the first
X-platform results are very good, given that I haven't "tuned" the tests
for x-platform compatibility yet.Ulf
Jani Taskinen schrieb:
Well, connection issues using mysqlnd seems to be pretty commonly
reported, like this:
Aaah, you're talking about mysqlnd @ ext/mysql[i] - different story
altogether.
There are 20 open reports currently:
It seems that Pierre's hypothesis that the community would take care and
help out is wrong. Andrey and I work on a different projects since a few
months. Its been only a development sprint that made me getting back to PHP.
No doubt we need to fix them. Andrey ^.
Ulf
Jani Taskinen schrieb:
Well, connection issues using mysqlnd seems to be pretty commonly
reported, like this:
http://bugs.php.net/45468Aaah, you're talking about mysqlnd @ ext/mysql[i] - different story
altogether.There are 20 open reports currently:
http://bugs.php.net/search.php?cmd=display&bug_type[]=MySQL
+related&bug_type[]=MySQLi
+related&status=Open&order_by=id&phpver=5&limit=50It seems that Pierre's hypothesis that the community would take care
and help out is wrong. Andrey and I work on a different projects
since a few months. Its been only a development sprint that made me
getting back to PHP.
there are also a few in PECL:
http://pecl.php.net/bugs/search.php?
cmd=display&status=Open&package_name[]=PDO_mysql
generally all of PDO suffers from the lack of maintainers ..
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith schrieb:
there are also a few in PECL:
http://pecl.php.net/bugs/search.php?cmd=display&status=Open&package_name[]=PDO_mysql
Ok, that's PDO_MYSQL. We checked both pecl.php.net and php.net bug
lists. Are there any plans to improve the PHP bug systems to allow:
- prioritizing a bug
- add progress reports
This would help to, for example, mark
http://pecl.php.net/bugs/bug.php?id=12401 as "in progress" or is that
"assigned". But "assigned" often means "yes, I should, but next year...".
Ulf
Lukas Kahwe Smith schrieb:
there are also a few in PECL:
http://pecl.php.net/bugs/search.php?cmd=display&status=Open&package_name
[]=PDO_mysqlOk, that's PDO_MYSQL. We checked both pecl.php.net and php.net bug
lists. Are there any plans to improve the PHP bug systems to allow:
- prioritizing a bug
- add progress reports
This would help to, for example, mark http://pecl.php.net/bugs/bug.php?id=12401
as "in progress" or is that "assigned". But "assigned" often means
"yes, I should, but next year...".
check with barry .. also note http://wiki.php.net/issuetracker
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Hi Ulf,
Am Montag, den 14.07.2008, 13:30 +0200 schrieb Ulf Wendel:
[...]
Cross platform testing has been performed on:
AIX 5.3 ppc64
FC4 x86
FreeBSD 6 x86, x86_64
HP UX 11.23 ia64
MacOS X 10.4 ppc32, x86
RHEL 3 ia64, x86, x86_64
RHEL 4 ia64, x86, x86_64
SLES 9 ia64, x86, x86_64
Suse 10.3 x86, x86_64
Win32
Is there a way to checkout the source. I would love to test PDO_MYSQLND.
cu, Lars
Hi Lars!
Lars Strojny schrieb:
Is there a way to checkout the source. I would love to test PDO_MYSQLND.
Not yet. Andrey will need a day or so. I've CC'd him. He can post
instructions here.
The internal mysqlnd repostory, which includes the code for PDO_MYSQLND,
was among the first to be migrated to Bazaar. This was long before the
migration of the MySQL trees was announced [1] and long before the
infrastructure for public access was ready.
Blame me for not pushing on public access to the bzr repro earlier...
Ulf
[1]
http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks-bitkeeper-welcome-bazaar/
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
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.
The impact is that users on Windows will no longer be able to connect
to the older databases unless they compile the extension themselves.
The benefit is reduced user confusion and PDO maintenance.
The change is to remove the pdo-oci8 section of ext/pdo_oci/config.w32
and tidy up associated Windows DLL release infrastructre.
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
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.The impact is that users on Windows will no longer be able to connect
to the older databases unless they compile the extension themselves.The benefit is reduced user confusion and PDO maintenance.
The change is to remove the pdo-oci8 section of ext/pdo_oci/config.w32
and tidy up associated Windows DLL release infrastructre.
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).
regards,
Lukas Kahwe Smith
mls@pooteeweet.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
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.
Well for Oracle 7 I can definitely see it, but Oracle 8 will still be
in production in plenty of places. I am fine with not supporting them
out of the box, but I think we should try to offer them a download
from PECL by the time 5.3.0 ships. That being said the world will not
end for me if we do not provide this, especially since I assume very
few people will have Oracle 8 and running a PDO based app on windows.
Most people will probably be using ext/oci8 for this kind of setup.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
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.Well for Oracle 7 I can definitely see it, but Oracle 8 will still be in
production in plenty of places. I am fine with not supporting them out
of the box, but I think we should try to offer them a download from PECL
by the time 5.3.0 ships. That being said the world will not end for me
if we do not provide this, especially since I assume very few people
will have Oracle 8 and running a PDO based app on windows. Most people
will probably be using ext/oci8 for this kind of setup.
Of the Oracle 8.x releases, there will be more 8.1 in use than 8.0 and
only the latter is directly affected. Php_pdo_oci.dll will connect to
Oracle 8.1.
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
Lukas Kahwe Smith wrote:
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.Well for Oracle 7 I can definitely see it, but Oracle 8 will still
be in
production in plenty of places. I am fine with not supporting them
out
of the box, but I think we should try to offer them a download
from PECL
by the time 5.3.0 ships. That being said the world will not end
for me
if we do not provide this, especially since I assume very few people
will have Oracle 8 and running a PDO based app on windows. Most
people
will probably be using ext/oci8 for this kind of setup.Of the Oracle 8.x releases, there will be more 8.1 in use than 8.0 and
only the latter is directly affected. Php_pdo_oci.dll will connect to
Oracle 8.1.
Ah ok, I was thinking 8.x .. now it makes more sense to me.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
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.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
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