# 5.3 Release Planning - Thread: https://externals.io/message/36005 - Original archive: https://news-web.php.net/php.internals/36005 - Started by johannes@php.net on 2008-03-06T17:10:27+00:00 - Messages: 28 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/36005.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #36005 — johannes@php.net — 2008-03-06T17:10:27+00:00 URL: https://externals.io/message/36005#36005 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] http://www.mail-archive.com/internals@lists.php.net/msg31117 [2] 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 --- ## #36007 — Marcus Boerger — 2008-03-06T17:24:38+00:00 URL: https://externals.io/message/36005#36007 · In reply to: #36005 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 --- ## #36010 — Antony Dovgal — 2008-03-06T17:36:04+00:00 URL: https://externals.io/message/36005#36010 · In reply to: #36005 > 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 --- ## #36012 — Cristian Rodriguez — 2008-03-06T18:02:52+00:00 URL: https://externals.io/message/36005#36012 · In reply to: #36010 2008/3/6, Antony Dovgal : > 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 --- ## #36014 — Stanislav Malyshev — 2008-03-06T18:11:07+00:00 URL: https://externals.io/message/36005#36014 · In reply to: #36005 > - 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 --- ## #36015 — Stanislav Malyshev — 2008-03-06T18:12:29+00:00 URL: https://externals.io/message/36005#36015 · In reply to: #36012 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 --- ## #36025 — Andi Gutmans — 2008-03-06T23:18:07+00:00 URL: https://externals.io/message/36005#36025 · In reply to: #36010 > -----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 --- ## #36026 — Andi Gutmans — 2008-03-06T23:21:09+00:00 URL: https://externals.io/message/36005#36026 · In reply to: #36012 > -----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 --- ## #36032 — Antony Dovgal — 2008-03-07T08:48:20+00:00 URL: https://externals.io/message/36005#36032 · In reply to: #36025 > > […] > > 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 --- ## #36033 — johannes@php.net — 2008-03-07T09:23:24+00:00 URL: https://externals.io/message/36005#36033 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 --- ## #36034 — phpxcache — 2008-03-07T09:27:06+00:00 URL: https://externals.io/message/36005#36034 · In reply to: #36005 i just hope the issue described in 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 --- ## #36035 — Antony Dovgal — 2008-03-07T09:28:24+00:00 URL: https://externals.io/message/36005#36035 > 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 --- ## #36036 — Alexey Zakhlestin — 2008-03-07T09:32:41+00:00 URL: https://externals.io/message/36005#36036 · In reply to: #36035 > > > […] > > > 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/ --- ## #36037 — Antony Dovgal — 2008-03-07T09:36:51+00:00 URL: https://externals.io/message/36005#36037 · In reply to: #36036 > > […] > > 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 --- ## #36043 — Steph Fox — 2008-03-07T13:09:03+00:00 URL: https://externals.io/message/36005#36043 · In reply to: #36037 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 --- ## #36044 — Antony Dovgal — 2008-03-07T13:22:04+00:00 URL: https://externals.io/message/36005#36044 · In reply to: #36043 > Hi Tony, > > > […] > > 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 --- ## #36045 — Steph Fox — 2008-03-07T13:36:08+00:00 URL: https://externals.io/message/36005#36045 · In reply to: #36044 > 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. > > […] - Steph > > -- > Wbr, > Antony Dovgal --- ## #36046 — Gregory Beaver — 2008-03-07T15:15:47+00:00 URL: https://externals.io/message/36005#36046 · In reply to: #36035 Antony Dovgal wrote: > > > […] > > 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 --- ## #36047 — Antony Dovgal — 2008-03-07T15:18:37+00:00 URL: https://externals.io/message/36005#36047 · In reply to: #36046 > I wholeheartedly agree that phar needs more testing. I also think some > other areas of php could have used more testing Undoubtedly. > > […] > > 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 --- ## #36073 — Mike Lively — 2008-03-10T04:52:33+00:00 URL: https://externals.io/message/36005#36073 · In reply to: #36005 > 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. --- ## #36074 — Lars Strojny — 2008-03-10T07:26:30+00:00 URL: https://externals.io/message/36005#36074 · In reply to: #36073 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 --- ## #36082 — Stanislav Malyshev — 2008-03-10T16:49:26+00:00 URL: https://externals.io/message/36005#36082 · In reply to: #36073 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 --- ## #36084 — Mike Lively — 2008-03-11T01:17:57+00:00 URL: https://externals.io/message/36005#36084 · In reply to: #36082 > Hi! > > > […] > a > > […] > > 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 --- ## #36086 — Stanislav Malyshev — 2008-03-11T01:41:02+00:00 URL: https://externals.io/message/36005#36086 · In reply to: #36084 > 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 --- ## #36099 — Mike Lively — 2008-03-11T13:56:56+00:00 URL: https://externals.io/message/36005#36099 · In reply to: #36086 > 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 --- Next page: https://externals.io/message/36005.md?page=2