Can I get an affirmation if the pdo dblib code will be accepted in 5.2
and 5.3 branches?
Hi Stanley
2010/7/2 Stanley Sufficool ssufficool@gmail.com:
Can I get an affirmation if the pdo dblib code will be accepted in 5.2
and 5.3 branches?
You need to talk to each of the release masters for this. If the
merges contains new features then it shouldn't go into 5.2, like the
LastInsertId you recently did. For 5.3 its a possibility if Johannes
agrees on it, I looked at the commits and I think they would be fit
for 5.3.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
hi,
For current releases, I don't think we should. The 2nd RCs have
released yesterday and it would really rock we can get the final out
asap (I suspect we may need one more RC...).
Cheers,
Can I get an affirmation if the pdo dblib code will be accepted in 5.2
and 5.3 branches?--
PDO Working Group Mailing List (http://pdo.php.net)
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Can I get an affirmation if the pdo dblib code will be accepted in 5.2
and 5.3 branches?
It shouldn't go into 5.2 if it introduces new functionality. You
might backport the crash/leak bug fixes if Ilia is OK with that.
Depending if how compatible (UI + protocol) it is with 5.3, then
Johannes may accept it into 5.3.4.
I'm concerned that recent PDO changes (including Ilia's merge of
inTransaction() for Postgres) haven't been documented. Lack of
accurate documentation won't help the consistency of further PDO
driver changes.
Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Free PHP Book: http://tinyurl.com/ugpomhome
On Fri, Jul 2, 2010 at 8:45 AM, Christopher Jones
christopher.jones@oracle.com wrote:
Can I get an affirmation if the pdo dblib code will be accepted in 5.2
and 5.3 branches?It shouldn't go into 5.2 if it introduces new functionality. You
might backport the crash/leak bug fixes if Ilia is OK with that.
Patches for the OOM for 5.2 and 5.3 are attached to BUG #50755
http://bugs.php.net/bug.php?id=50755
There has been feedback on this bug that indicates other are needing
this fix as well. This prevents people from developing bigger
applications on non-MS Platforms to support SQL Server and Sybase.
I would argue that the additional fixes in trunk fix bugs rather than
introducing new functionality since they were already in the PDO
specification and they do not break BC. I do not see why this would be
held out of releases. This passes most PDO tests and passes other
tests in ext/pdo_dblib/tests. The PDO tests that fail, AFAIK have
always failed.
FWIW, Microsoft has a monopoly on a fully functional PDO mssql driver
which is only implemented on MS platforms. If we want portability of
PHP applications, then the PDO DBLIB driver must be fully functional
on releases.
BTW, This extension is experimental and subject to change. Well it
did, and they were warned.
Happy Independence Day,
Stan
Depending if how compatible (UI + protocol) it is with 5.3, then
Johannes may accept it into 5.3.4.I'm concerned that recent PDO changes (including Ilia's merge of
inTransaction() for Postgres) haven't been documented. Lack of
accurate documentation won't help the consistency of further PDO
driver changes.Chris
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Free PHP Book: http://tinyurl.com/ugpomhome
hi,
I would argue that the additional fixes in trunk fix bugs rather than
introducing new functionality since they were already in the PDO
specification and they do not break BC. I do not see why this would be
held out of releases.
They should, only not right now in 5.3.3/5.2.14 as we are in the
second release candidates. The reasons why we should not begin to
apply dozen of patches at this stage are rather obvious, hopefully :).
FWIW, Microsoft has a monopoly on a fully functional PDO mssql driver
which is only implemented on MS platforms. If we want portability of
PHP applications, then the PDO DBLIB driver must be fully functional
on releases.
That's not correct. PHP 5.3+ has no SqlServer support on Windows. The
SqlSrv driver is more than welcome as it solves this problem. The PDO
support is still beta (CTP2). However all other platforms do have
SqlServer support by default in the core.
BTW, This extension is experimental and subject to change. Well it
did, and they were warned.
Hence the worries? :)
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
I would argue that the additional fixes in trunk fix bugs rather than
introducing new functionality since they were already in the PDO
specification and they do not break BC. I do not see why this would be
held out of releases.They should, only not right now in 5.3.3/5.2.14 as we are in the
second release candidates. The reasons why we should not begin to
apply dozen of patches at this stage are rather obvious, hopefully :).
Got it. Thanks.
FWIW, Microsoft has a monopoly on a fully functional PDO mssql driver
which is only implemented on MS platforms. If we want portability of
PHP applications, then the PDO DBLIB driver must be fully functional
on releases.That's not correct. PHP 5.3+ has no SqlServer support on Windows. The
SqlSrv driver is more than welcome as it solves this problem. The PDO
support is still beta (CTP2). However all other platforms do have
SqlServer support by default in the core.
Sorry, I was incorrect, the Microsoft PDO SqlServer is still in
release candidate stages. I'm just hoping to have an on-par PDO
implementation available on all platforms before everyone starts
coding for the platform dependent driver.
BTW, This extension is experimental and subject to change. Well it
did, and they were warned.Hence the worries? :)
I am saying that this extension on the PHP doc pages is marked as
experimental and as such the users should not expect the behavior to
stay consistent. But none-the-less, the patches do not affect any
existing behavior. So no worries. :)
--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
That's not correct. PHP 5.3+ has no SqlServer support on Windows. The
SqlSrv driver is more than welcome as it solves this problem. The PDO
support is still beta (CTP2). However all other platforms do have
SqlServer support by default in the core.Sorry, I was incorrect, the Microsoft PDO SqlServer is still in
release candidate stages. I'm just hoping to have an on-par PDO
implementation available on all platforms before everyone starts
coding for the platform dependent driver.
It does not matter for PDO. They have the same API and the queries
should be the same. A couple of features may not work in the same way,
mainly the auth parts. It is however the case for the sqlsrv driver
API (non PDO). But even in this case the API is very close to what we
have in mssql, only with less bugs ;)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Can I get an affirmation if the pdo dblib code will be accepted in 5.2
and 5.3 branches?
In general bug fixes should go to all active branches. Right now these
are 5.2, 5.3 and trunk. Right now 5.2 and 5.3 are in RC so only
"critical" stuff should go in. Afaik this will be the last "regular" 5.2
release only followed only by security related releases from that
branch, but that's up to Ilia. Now the question is about the definition
for "critical" stuff, in doubt that has to be decided by the extension
maintainer and the RMs case by case. (how critical is the issue for
users? how complex(=risky) is the patch? ...) According to the
EXTENSIONS file pdo_dblib isn't maintained right now so thank you for
volunteering to take over that role.
johannes
PHP 5.2 branch is really for bug fixes only, so new functionality
should be introduced into it.
Can I get an affirmation if the pdo dblib code will be accepted in 5.2
and 5.3 branches?
PHP 5.2 branch is really for bug fixes only, so new functionality
should be introduced into it.
+not
:)
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org