5.3 Release Planning

17 years ago by johannes@php.net — view source

unread

Hi all,

recently there were quite a few proposals about stuff for 5.3. If we implement
them all we won't finish in a "soonish" time and we get new ideas postponing
the 5.3 release therefore the following:

Scanner based on re2c:
Going to re2c promises to make maintenance simpler and increase the parsers
performance. Currently the prototype does not provide support for Zend
multibyte mode. This seems doable within April. Hence I ask for finishing
by end of April the latest. Once that is done we will go over to a freeze and
switch to bug fixing only mode.
If this is done sooner than we'll freeze sooner, too. If there are delays
we'll freeze anyways and use the scanner for a later release.
bundling pecl/intl
According to Stas it's ready for being bundled and was voted in. The only
question I see there is the "how to bundle it". There we should definitely
find a better thing than symlinking around on the CVS server, an option
might be to to switch to subversion and use svn:externals or keeping stuff
in pecl and then having some scripts (maybe part of buildconf/the release
scripts) fetching them into a checkout. Just ideas ... For the moment
symlinking might be the best.
bundling pecl/phar
Lots of work has been done there, I'd like to have it in, general PECL
discussion: See above.
Large File Support
That's a thing on the todo for ages. A patch was proposed by Wez once[1]. The
patch should be, according to Wez, improved to use php_config.h for the
defines instead of passing them using CFLAGS. Additionally one should mind
Joe's comments[2] in that old thread. If somebody has time I'd welcome it, if
not: It waited for so long already so it might wait a bit more. ;-)

[1] internals@lists.php.net/msg31117" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg31117
[2] internals@lists.php.net/msg31124" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg31124
All the other stuff
Extension maintainers always like improving their extensions, There will be
improvements to GD I think and other stuff, I don't list that all - the
timeline is mentioned above.
Fixes&Testing
Test snaps, report bugs, fix bugs, ... That's the most important thing. That's
where really everybody reading this can contribute and do important things. :-)

You might miss some stuff in the list above, at first one might think about
these:

Traits: Interesting concept, basically most of us want it, some decision
about some details needed, then some implementation, i had a short discussion
with Stefan and we agreed that we don't call it "release critical" for 5.3 and
plan 5.3 without traits.
Closures/Anonymous functions: Basically the same as with traits, some detail
discussions left, then a bit time for updating the patches, not planned for 5.3.

Surrounding all this stuff we'd also have another topic we should start
working on:

Updating guide, something like README.UPDATE_5_2. I think our new wiki
might be a good place to create such a list. I'll find some place there
and come than back to the list, but you might already start thinking
about stuff you know that should be mentioned there. That's again a
thing everybody can contribute.

That's enough for the moment,
johannes
PHP 5.3 RM

17 years ago by Marcus Boerger — view source

unread

Hello Johannes,

Thursday, March 6, 2008, 6:10:27 PM, you wrote:

Hi all,

recently there were quite a few proposals about stuff for 5.3. If we implement
them all we won't finish in a "soonish" time and we get new ideas postponing
the 5.3 release therefore the following:

Scanner based on re2c:
[...]
Anyone interested more in this one might
a) have a look here: http://blog.somabo.de/2008/02/php-on-re2c.html
b) provide tests for configure --enable-zend-multibyte (and whatever you
use it for)

Best regards,
Marcus

17 years ago by Antony Dovgal — view source

unread

Hi all,

recently there were quite a few proposals about stuff for 5.3. If we implement
them all we won't finish in a "soonish" time and we get new ideas postponing
the 5.3 release therefore the following:

I'd like to ask to re-consider dropping ze1_compatibility_mode and finally drop it in 5.3.
It just doesn't work, so there is no point to keep it.

--
Wbr,
Antony Dovgal

17 years ago by Cristian Rodriguez — view source

unread

2008/3/6, Antony Dovgal tony@daylessday.org:

It just doesn't work, so there is no point to keep it.

That statement is very true, it does not work at all.

Also will be nice if zend.enable_gc ini setting is dropped as well
before it is too late , having yet another ini setting that alters the
engine behaviuor looks pretty much like the repeating the same old
mistakes over and over again.

either GC or dont, please.

--
"If debugging is the process of removing bugs, then programming must
be the process of putting them in." – Edsger Dijkstra

http://www.cristianrodriguez.net

17 years ago by Stanislav Malyshev — view source

unread

Hi!

Also will be nice if zend.enable_gc ini setting is dropped as well
before it is too late , having yet another ini setting that alters the
engine behaviuor looks pretty much like the repeating the same old
mistakes over and over again.

Does it alter the engine behaviour? I was under impression the behavior
is the same, just the moment when memory is reclaimed has changed. Does
it mean there's code that works differently with GC than without?

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

17 years ago by Andi Gutmans — view source

unread

-----Original Message-----
From: Cristian Rodriguez [mailto:judas.iscariote@gmail.com]
Sent: Thursday, March 06, 2008 10:03 AM
To: php-dev
Subject: Re: [PHP-DEV] 5.3 Release Planning

Also will be nice if zend.enable_gc ini setting is dropped as well
before it is too late , having yet another ini setting that alters the
engine behaviuor looks pretty much like the repeating the same old
mistakes over and over again.

either GC or dont, please.

There is no functional implication and you will see the same behavior (except for memory usage and performance). Also I think we agreed this would not be a phpinfo() INI setting but one we can turn off for debugging purposes because until it's completely stable there may be GC bugs (we've had several). Also during the rollout process it'll help us triage performance issues if they come up (Turn it off and let us know if you feel a difference). Of course the bookkeeping is always on.

So suggest to keep it in, not in phpinfo() and see how things roll out.

Andi

17 years ago by Andi Gutmans — view source

unread

-----Original Message-----
From: Antony Dovgal [mailto:tony@daylessday.org]
Sent: Thursday, March 06, 2008 9:36 AM
To: Johannes Schlüter
Cc: PHP Internals List
Subject: Re: [PHP-DEV] 5.3 Release Planning

I'd like to ask to re-consider dropping ze1_compatibility_mode and
finally drop it in 5.3.
It just doesn't work, so there is no point to keep it.

Yes I think it makes sense.
Do we just document it in the UPGRADING doc or for 5.3 raise an E_ERROR with an error message? s

17 years ago by Antony Dovgal — view source

unread

I'd like to ask to re-consider dropping ze1_compatibility_mode and
finally drop it in 5.3.
It just doesn't work, so there is no point to keep it.

Yes I think it makes sense.
Do we just document it in the UPGRADING doc or for 5.3 raise an E_ERROR with an error message? s

No errors, please.
Just a warning in the docs and in the official announcement.

--
Wbr,
Antony Dovgal

17 years ago by Stanislav Malyshev — view source

unread

bundling pecl/intl
According to Stas it's ready for being bundled and was voted in. The only

Most of it is ready, since 5.3 took more time that we initially thought
we also added dateformatter functionality there, which right now has
last wrinkles straightened out - code is mostly complete, docs in the
works, there might be minor API optimizations and bugfixes, but in
general we could certainly merge it by the end of April. I don't want to
symlink it until we have the code 100% done, but we are very close.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

17 years ago by phpxcache — view source

unread

i just hope the issue described in
internals@lists.php.net/msg32601.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg32601.html will
be resolved before 5.3 is out. it is the only problem that breaks
opcode cacher support as far as i can see by now. e.g.: with this
problem fixed, all test cases will pass when XCache is enabled but not
without fixed

17 years ago by Mike Lively — view source

unread

Hi all,

recently there were quite a few proposals about stuff for 5.3. If we
implement
them all we won't finish in a "soonish" time and we get new ideas
postponing
the 5.3 release therefore the following:

One thing that never really was resolved were the patches I submitted as a
compromise to some of the early disagreements about late static binding.

http://marc.info/?l=php-internals&m=119605755711936&w=2

There was a little bit of discussion but it was quickly overshadowed by talk
of brackets, imports, and other things. I don't necessarily think all of the
arguments need to be rehashed again as they have been beaten to death, it
would just be good to get an actual decision on whether or not one of them
(hopefully the parent:: one) can make it in.

If so I can update whichever patch.

17 years ago by Lars Strojny — view source

unread

Hi Mike,

Am Sonntag, den 09.03.2008, 21:52 -0700 schrieb Mike Lively:
[...]

+1 for lsb.parent-forwarding.patch as the implemented behaviour will be
expected from our users anyway.

cu, Lars

17 years ago by Stanislav Malyshev — view source

unread

Hi!

One thing that never really was resolved were the patches I submitted as a
compromise to some of the early disagreements about late static binding.

I don't think it's a good ideas as it changes the meaning of parent::.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

17 years ago by Mike Lively — view source

unread

Hi!

One thing that never really was resolved were the patches I submitted as
a
compromise to some of the early disagreements about late static binding.

I don't think it's a good ideas as it changes the meaning of parent::.

I disagree, the meaning of parent:: is not changed at all relative to php
5.2.*. It behaves exactly the same with the parent forwarding patch. If you
call parent::method() the parent version of the method is still called. It
just provides complete polymorphic calls with static functions which is the
whole purpose for which LSB was even proposed.

Regardless of that, there are two other patches that do the same thing
without altering the behaviour of parent in the current 5.3 code. Though
again, I would think it very unfortunate should we not fix it properly and
just allow parent:: to forward the caller.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

17 years ago by Stanislav Malyshev — view source

unread

I disagree, the meaning of parent:: is not changed at all relative to
php 5.2.*. It behaves exactly the same with the parent forwarding patch.

I must be misunderstanding the patch then - doesn't it change behavior
of the engine so that parent:: doesn't mean "parent of CLASS"
anymore? If so, could you explain again what it does?

without altering the behaviour of parent in the current 5.3 code. Though
again, I would think it very unfortunate should we not fix it properly
and just allow parent:: to forward the caller.

parent:: is very simple thing - it means "use the name of the parent
class here". I do not thing changing it is a good idea.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

17 years ago by Mike Lively — view source

unread

I must be misunderstanding the patch then - doesn't it change behavior
of the engine so that parent:: doesn't mean "parent of CLASS"
anymore? If so, could you explain again what it does?

Of course parent:: still means parent. The change in behavior from the
current patch is just that once you call parent::someMethod you will still
have access to overridden methods in child classes which with the current
patch is not possible. Again, it just provides complete polymorphism for
statics.

parent:: is very simple thing - it means "use the name of the parent

class here". I do not thing changing it is a good idea.

I am of the opinion that parent:: simply means call the parent function
which doesn't change with the patch. I understand that you do not think it
is a good, but I and many other people that have expressed their opinion on
list regarding this matter disagree with you. You seem to be very focused on
the parent:: issue without looking at the whole picture.

Like I said before, I think all of the arguments have been hashed out. I
would just like a yes or no decision that preferably reflects the desire of
the user base. It would be fantastic if some more decision makers had some
time to give their input.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

17 years ago by Stanislav Malyshev — view source

unread

Hi!

Of course parent:: still means parent. The change in behavior from the
current patch is just that once you call parent::someMethod you will
still have access to overridden methods in child classes which with the
current patch is not possible. Again, it just provides complete
polymorphism for statics.

OK, looks like I misunderstood what your patch does. Sorry for that.
However, I'm still concerned that foo:: and parent:: would work
differently. IMO, better solution would be to have all :: calls change
called_class, but have also some way to call it without changing
called_class. Something like your forward_static_call, but I'm not sure
not using callbacks is a good idea - all caller function use callbacks
now. Actually, what I'd do would be to generalize forward_static_call
(which I think also needs better name :) and call_user_func into one
function (internally) that has parameter which tells if to update or not
update called_class.

Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

17 years ago by Mike Lively — view source

unread

IMO, better solution would be to have all :: calls change
called_class, but have also some way to call it without changing
called_class. Something like your forward_static_call, but I'm not sure
not using callbacks is a good idea - all caller function use callbacks
now. Actually, what I'd do would be to generalize forward_static_call
(which I think also needs better name :) and call_user_func into one
function (internally) that has parameter which tells if to update or not
update called_class.

I do agree about using a callback with forward_static_call, but one thing
that worries me is that opens the door to really bizzare functionality where
the called_class could wind up being outside of the inheritance chain of the
method being called.

If this could be overcame I think it would be relatively easy to consolidate
this code internally. I will look at it this evening and tomorrow.

--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com

17 years ago by Robin Fernandes — view source

unread

Hi Johannes,

This bug suggests the output buffering re-write in HEAD would be
backported to 5_3: http://bugs.php.net/bug.php?id=42641
Is that still in plan?

I have added it as a "To be discussed" item on http://wiki.php.net/todo/php53.

Regards,
Robin

17 years ago by johannes@php.net — view source

unread

Hi,

Just a quick note: I'd like to consider another possible approach,
having pecl/phar synced from stable pecl release.

Yes, that's what I'd like, too. Te problem there is that developers
using CVS checkouts should get a CVS checkout f it, too so it's being
tested and can be fixed if needed. And if you read my mail you see that
I mentioned doing it during buildconf, which is better than configure, I
think ;-)

I am also fine with symlinking until this can be perfected, as it is
just an idea to be implemented right now.

right. /me has no powers for actually doing that.

johannes

17 years ago by Antony Dovgal — view source

unread

Just a quick note: I'd like to consider another possible approach,
having pecl/phar synced from stable pecl release.

I'm not sure it's good idea.
IMO it should go trough much more thorough testing to be included into the core.

And I'm still not convinced we should include any PECL extensions in the core,
I believe it should go the other way round.

--
Wbr,
Antony Dovgal

17 years ago by Alexey Zakhlestin — view source

unread

Just a quick note: I'd like to consider another possible approach,
having pecl/phar synced from stable pecl release.

I'm not sure it's good idea.
IMO it should go trough much more thorough testing to be included into the core.

And I'm still not convinced we should include any PECL extensions in the core,
I believe it should go the other way round.

it would be better to say not "in core", but "in official distribution"
until there is convenient cross-platform of installing extensions from
pecl, important ones should be included in distribution

--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/

17 years ago by Antony Dovgal — view source

unread

I'm not sure it's good idea.
IMO it should go trough much more thorough testing to be included into the core.

And I'm still not convinced we should include any PECL extensions in the core,
I believe it should go the other way round.

it would be better to say not "in core", but "in official distribution"

PECL is officially distributed either.
What I mean by the "core" is ext/ subdirectory of the sources tarball.

until there is convenient cross-platform of installing extensions from
pecl, important ones should be included in distribution

Well, lets make it convenient then.
Including everything into the core is not a solution.

--
Wbr,
Antony Dovgal

17 years ago by Steph Fox — view source

unread

Hi Tony,

Well, lets make it convenient then.
Including everything into the core is not a solution.

You seem to have missed an entire thread on the subject, along with the
conclusion that the mechanisms for really doing a good job on this can't
sanely be in place before 5.3.0 is released. They will need thorough testing
before we start moving stuff out of core, and there just isn't time for
that. It's more likely to be 5.4 before we can call it 'reliable'.

What Greg's suggesting is that if phar goes into the distro, it can act as
an early live test subject.

Steph

17 years ago by Antony Dovgal — view source

unread

Hi Tony,

Well, lets make it convenient then.
Including everything into the core is not a solution.

You seem to have missed an entire thread on the subject, along with the
conclusion that the mechanisms for really doing a good job on this can't
sanely be in place before 5.3.0 is released. They will need thorough testing
before we start moving stuff out of core, and there just isn't time for
that. It's more likely to be 5.4 before we can call it 'reliable'.

The very same could be said about phar.

What Greg's suggesting is that if phar goes into the distro, it can act as
an early live test subject.

--
Wbr,
Antony Dovgal

17 years ago by Steph Fox — view source

unread

The very same could be said about phar.

It's going through a final wave of intensive development that adds to
existing features; the core functionality's solid, and has been for some
time. Given the end of April 'freeze', we're at least 2 months away from a
5.3 release. Assuming Greg's include patch or something akin to it is
accepted into 5.3, all of that is fine-tuning time.

What Greg's suggesting is that if phar goes into the distro, it can act
as
an early live test subject.

Steph

--
Wbr,
Antony Dovgal

17 years ago by Gregory Beaver — view source

unread

Antony Dovgal wrote:

Just a quick note: I'd like to consider another possible approach,
having pecl/phar synced from stable pecl release.

I'm not sure it's good idea.
IMO it should go trough much more thorough testing to be included into the core.

Hi,

I wholeheartedly agree that phar needs more testing. I also think some
other areas of php could have used more testing, such as the serious
issues I found in zlib stream filters, but they were useful for years
even with edge case flaws. Areas that I know phar needs work:

big-endian like PPC tar/zip support is incomplete, I need to write
the simple byte order reversal that will complete this, and add the same
compiler flags to the tar struct that we use on zip structs. This is an
easy fix.
finishing up include_path support for streams. Other threads address
this issue. This will remove the need for most of the proposed magic in
pecl/phar/TODO.
ensuring full code coverage of tests, we're currently at about 68-70%
finishing up Steph's work on data-only tar/zip support
(non-executable tar/zip read/write)
2 open bugs at pecl.php.net
more hammering should be done on the web front controller to ensure
edge cases have been considered

Areas of phar that are rock-solid:

phar stream read/write
file format support for the 3 file formats read/write
anything else not yet mentioned.

I expect to be able to wrap up the issues listed very quickly. Tony has
been fantastic at finding memleaks/segfaults as new features are added,
and we welcome the minutest scrutiny.

And I'm still not convinced we should include any PECL extensions in the core,
I believe it should go the other way round.

This is secondary, but I'm proposing using phar to test the mechanism
that will allow ext/ to migrate to pecl/ and still work as it did in ext/

Greg

17 years ago by Antony Dovgal — view source

unread

I wholeheartedly agree that phar needs more testing. I also think some
other areas of php could have used more testing

Undoubtedly.

And I'm still not convinced we should include any PECL extensions in the core,
I believe it should go the other way round.

This is secondary, but I'm proposing using phar to test the mechanism
that will allow ext/ to migrate to pecl/ and still work as it did in ext/

Ok, here I guess I should and read that thread Steph mentioned..

--
Wbr,
Antony Dovgal

5.3 Release Planning

Does it alter the engine behaviour? I was under impression the behavior is the same, just the moment when memory is reclaimed has changed. Does it mean there's code that works differently with GC than without?

I don't think it's a good ideas as it changes the meaning of parent::.

parent:: is very simple thing - it means "use the name of the parent class here". I do not thing changing it is a good idea.

Does it alter the engine behaviour? I was under impression the behavior
is the same, just the moment when memory is reclaimed has changed. Does
it mean there's code that works differently with GC than without?

parent:: is very simple thing - it means "use the name of the parent
class here". I do not thing changing it is a good idea.