# PHP 5.4 branch and trunk - Thread: https://externals.io/message/47310 - Original archive: https://news-web.php.net/php.internals/47310 - Started by Derick Rethans on 2010-03-16T15:58:25+00:00 - Messages: 38 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/47310.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 --- ## #47310 — Derick Rethans — 2010-03-16T15:58:25+00:00 URL: https://externals.io/message/47310#47310 Hello, I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved trunk to the branch FIRST_UNICODE_IMPLEMENTATION. The next things to do is to re-create trunk from PHP 5.3; I've hold off that for now, but I'd like to do the following soon: - Declare 5.2 security fixes only (Something for Ilia to declare). - Declare 5.3 bug fixes only (and ini-mini features if so desired) (Something for Johannes to declare). Once that's done, I'd like to: - Recreate trunk from the 5.3 branch. Before we add features, they need to be discussed whether we want to have them. As version name for it I would like to use "trunk-dev" (and not 5.4-dev or 6.0-dev) as we're not quite sure where this is moving. Right now, there are the following features that I can see we should think about: - the new output buffering mechanism (I can not really see why we would not want this) - Scott's big number improvements. Scott, can you explain (in an RFC) what exactly this does and how it works? - Ilia's scalar type hint patch. There are RFCs: http://wiki.php.net/rfc/typechecking - traits, there are also RFCs: http://wiki.php.net/rfc/horizontalreuse http://wiki.php.net/rfc/nonbreakabletraits with kind regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #47312 — David Soria Parra — 2010-03-16T16:10:04+00:00 URL: https://externals.io/message/47310#47312 · In reply to: #47310 > - Declare 5.2 security fixes only (Something for Ilia to declare). > - Declare 5.3 bug fixes only (and ini-mini features if so desired) > (Something for Johannes to declare). > > Once that's done, I'd like to: > > - Recreate trunk from the 5.3 branch. > > - the new output buffering mechanism (I can not really see why we would > not want this) is there something about that in the wiki? I think a few lines in the wiki about this would be good. > - Scott's big number improvements. Scott, can you explain (in an RFC) > what exactly this does and how it works? > - Ilia's scalar type hint patch. There are RFCs: > http://wiki.php.net/rfc/typechecking > - traits, there are also RFCs: > http://wiki.php.net/rfc/horizontalreuse > http://wiki.php.net/rfc/nonbreakabletraits thank you. I agree that we should discuss new additions with proper rfcs before we commit them. in addition to that peopled interested in unicode should get together and discuss how to readd unicode support and in which way to do this. --- ## #47313 — Alexey Zakhlestin — 2010-03-16T16:11:03+00:00 URL: https://externals.io/message/47310#47313 · In reply to: #47310 > Right now, there are the following features that I can see we should > think about: > > - the new output buffering mechanism (I can not really see why we would >  not want this) > - Scott's big number improvements. Scott, can you explain (in an RFC) >  what exactly this does and how it works? > - Ilia's scalar type hint patch. There are RFCs: >  http://wiki.php.net/rfc/typechecking > - traits, there are also RFCs: >  http://wiki.php.net/rfc/horizontalreuse >  http://wiki.php.net/rfc/nonbreakabletraits + merge php-fpm branch? -- Alexey Zakhlestin http://www.milkfarmsoft.com/ --- ## #47315 — Derick Rethans — 2010-03-16T16:13:07+00:00 URL: https://externals.io/message/47310#47315 · In reply to: #47313 > > > > […] > > + merge php-fpm branch? Can't see why not. Is there an RFC for this? regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #47316 — Hannes Magnusson — 2010-03-16T16:15:02+00:00 URL: https://externals.io/message/47310#47316 · In reply to: #47312 > > > […] > is there something about that in the wiki? I think a few lines in the wiki > about this would be good. I doubt it. Its a rewrite which had to be done to simplify things and fixes several bugs. -Hannes --- ## #47319 — Sebastian Bergmann — 2010-03-16T16:43:56+00:00 URL: https://externals.io/message/47310#47319 · In reply to: #47310 Am 16.03.2010 16:58, schrieb Derick Rethans: > I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved > trunk to the branch FIRST_UNICODE_IMPLEMENTATION. Why do we need THE_5_4_THAT_ISNT_5_4 and trunk? trunk should be where the development happens. When the time comes for a release, PHP_X_Y should be branched off of trunk. -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #47320 — Pierre Joye — 2010-03-16T16:54:15+00:00 URL: https://externals.io/message/47310#47320 · In reply to: #47319 On Tue, Mar 16, 2010 at 5:43 PM, Sebastian Bergmann wrote: > Am 16.03.2010 16:58, schrieb Derick Rethans: > > […] > >  Why do we need THE_5_4_THAT_ISNT_5_4 Right, this branch must be deleted, useless. The OB patch can be merged again in trunk when trunk has been rebranched. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #47323 — Hannes Magnusson — 2010-03-16T18:07:48+00:00 URL: https://externals.io/message/47310#47323 · In reply to: #47320 > On Tue, Mar 16, 2010 at 5:43 PM, Sebastian Bergmann > wrote: > > […] > > Right, this branch must be deleted, useless. The OB patch can be > merged again in trunk when trunk has been rebranched. Why exactly do we need to duplicate the work? IMO that branch should be renamed to trunk/ and those 2 or 3 patches to 5.3 to merged into it. -Hannes --- ## #47324 — Hannes Magnusson — 2010-03-16T18:23:41+00:00 URL: https://externals.io/message/47310#47324 · In reply to: #47310 > Before we add features, they need to be discussed whether we want to > have them. Does that mean you want to take up a - strict RFC-and-after-3months-discussion-before-commit policy (i.e. killing the scratching-an-itch spirit of PHP) - "I'm going to commit this patch tomorrow" mail to internals@ (i.e. killing "I need this functionality, maybe others do to" spirit of PHP) or what exactly do you mean by that? I would much rather have a development branch which ""everything goes"" (like it used to) and then make it up to the release manager to merge the features he wants in "his branch" (DVCS style) > - Ilia's scalar type hint patch. And which of Ilias patches are you referring to? The original one (which is identical to the patch I sent in November 2006) or the "fucking eyh, I need to please everyone so this can be in 5.3 - but still got rejected" patch? You didn't even list the mbstring patch.. that was discussed and as far as I remember everyone thought it was great idea, just not in a stable branch. -Hannes --- ## #47332 — johannes@php.net — 2010-03-16T20:00:21+00:00 URL: https://externals.io/message/47310#47332 · In reply to: #47313 > + merge php-fpm branch? If we get a trunk which will be released in a foreseeable timeframe we don't need to merge this to 5.3 anymore, which had been an old plan. Tony, do you agree? johannes --- ## #47334 — Antony Dovgal — 2010-03-16T20:04:52+00:00 URL: https://externals.io/message/47310#47334 · In reply to: #47332 > > > […] > > If we get a trunk which will be released in a foreseeable timeframe we > don't need to merge this to 5.3 anymore, which had been an old plan. > Tony, do you agree? Makes sense to me. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP --- ## #47335 — Stanislav Malyshev — 2010-03-16T20:22:40+00:00 URL: https://externals.io/message/47310#47335 · In reply to: #47324 Hi! > Does that mean you want to take up a > - strict RFC-and-after-3months-discussion-before-commit policy > (i.e. killing the scratching-an-itch spirit of PHP) > - "I'm going to commit this patch tomorrow" mail to internals@ > (i.e. killing "I need this functionality, maybe others do to" spirit of PHP) Probably something like "I have this patch and I wrote this RFC, please discuss", then wait reasonable* time for discussion and reasonable* consensus before commit, and for reasonably* small patches "I'm going to commit it in 2 days unless somebody objects" would work (*) I know definitions of "reasonable" differ but I have faith we find a common ground. > And which of Ilias patches are you referring to? The original one > (which is identical to the patch I sent in November 2006) or the > "fucking eyh, I need to please everyone so this can be in 5.3 - but > still got rejected" patch? That's exactly why having RFC is good - one link solves all the questions about "which one is it' :) -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #47341 — Lukas Kahwe Smith — 2010-03-16T21:12:01+00:00 URL: https://externals.io/message/47310#47341 · In reply to: #47324 > > > […] > > Does that mean you want to take up a > - strict RFC-and-after-3months-discussion-before-commit policy > (i.e. killing the scratching-an-itch spirit of PHP) > - "I'm going to commit this patch tomorrow" mail to internals@ > (i.e. killing "I need this functionality, maybe others do to" spirit of PHP) Its all a question about the scope of the change obviously. There is some tipping point where it makes sense for an RFC. Remember an RFC not only serves decision making, but also provides some level of documentation (on which the final documentation can be build) for past generations (this is why I for example wrote the ifsetor RFC after we decided that we cannot currently implement it). So like Stas said .. common sense still rules. > I would much rather have a development branch which ""everything > goes"" (like it used to) and then make it up to the release manager to > merge the features he wants in "his branch" (DVCS style) I dont think we ever had an "everything goes" HEAD .. lets say in the past we had a small very active core dev team with really short turn around times for decisions because everybody was answering on IRC or mailinglists within minutes. As a result decisions (not always for the better) were made in a much shorter timeframe than the current availability of core developers affords us. > > […] > > And which of Ilias patches are you referring to? The original one > (which is identical to the patch I sent in November 2006) or the > "fucking eyh, I need to please everyone so this can be in 5.3 - but > still got rejected" patch? I think he clearly pointed to the wiki page which lists 3 proposals. He is just suggesting we should finalize which one we want and get it in. > You didn't even list the mbstring patch.. that was discussed and as > far as I remember everyone thought it was great idea, just not in a > stable branch. Is this tone really necessary? One you are argueing for more flexibility and then you are shooting the messenger because in a long list he forgot one thing (there are probably a few others .. we might want to go through the todo wiki pages for more)? regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #47342 — Lukas Kahwe Smith — 2010-03-16T21:13:54+00:00 URL: https://externals.io/message/47310#47342 · In reply to: #47310 > Before we add features, they need to be discussed whether we want to > have them. As version name for it I would like to use "trunk-dev" (and > not 5.4-dev or 6.0-dev) as we're not quite sure where this is moving. > Right now, there are the following features that I can see we should > think about: Since we do not know the name of the next version yet, maybe its best to base the name on what version it will have as a predecessor and add support for this in `version_compare()`? Something like "5.3post". Ok this isnt a good suggestion, but I hope you get what I am suggesting. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #47343 — Lukas Kahwe Smith — 2010-03-16T21:29:58+00:00 URL: https://externals.io/message/47310#47343 · In reply to: #47310 > I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved Eventually it should be deleted, if it helps at all in merging the OB change then it should be kept until that happens, otherwise it can be deleted now imho. The new 5.3 based trunk will emerge soon I am sure, but until then lets not bother with having to merge those changes. > trunk to the branch FIRST_UNICODE_IMPLEMENTATION. +1 > The next things to do is to re-create trunk from PHP 5.3; I've hold off > that for now, but I'd like to do the following soon: > > - Declare 5.2 security fixes only (Something for Ilia to declare). > - Declare 5.3 bug fixes only (and ini-mini features if so desired) > (Something for Johannes to declare). +1 > - the new output buffering mechanism (I can not really see why we would > not want this) +1 > - traits, there are also RFCs: > http://wiki.php.net/rfc/horizontalreuse > http://wiki.php.net/rfc/nonbreakabletraits +1 other stuff: http://wiki.php.net/todo/php60 http://wiki.php.net/todo/backlog That being said I think until we know if the next version will be a new major version, we should hold off on BC breaking cleanup stuff likes dropping register globals and friends. But we still might bundle APC with the next release for example, even if its not 6.0 .. -- As for unicode, I would like the next release to be planned independently of finding a solution for unicode, but with the clear option that it will be included if we find a good solution in time (like I said I think it would be good to shoot for a final release summer 2011, so beta phase in early 2011). I propose that sort of a unicode working group forms but much less formal than what I make it sound like. I think the discussions can remain on internals@ and hopefully alternative approaches will be documented as RFCs. But what I mean with working group is a list of a handful of names who feel responsible to keep this topic moving until a solution is found and who people know they can contact if they want to chat or whatever. Again if these guys find a workable solution that can be implemented this year and I am all for putting it into the next release. If not so be it, because I think the lesson learned in all of the PHP6/PHP5.3 release nightmare is that we should have regular releases. So I say we shoot for the release following the next one to come out in the summer of 2012. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #47346 — johannes@php.net — 2010-03-16T22:00:48+00:00 URL: https://externals.io/message/47310#47346 · In reply to: #47342 > > > > […] > > > Since we do not know the name of the next version yet, maybe its best to > base the name on what version it will have as a predecessor and add > support for this in `version_compare()`? Something like "5.3post". Ok this > isnt a good suggestion, but I hope you get what I am suggesting. We need a version number which can be represented as a numeric value like #define `PHP_VERSION_ID` 50303 to help extension authors; as said on IRC 5.4 is the only sane choice there. We can still increase the number if needed. How to document this is a good question... johannes --- ## #47350 — Jan Schneider — 2010-03-17T08:50:59+00:00 URL: https://externals.io/message/47310#47350 · In reply to: #47346 Zitat von Johannes Schlüter : > > > […] > > We need a version number which can be represented as a numeric value > like > > #define `PHP_VERSION_ID` 50303 > > to help extension authors; as said on IRC 5.4 is the only sane choice > there. We can still increase the number if needed. > > How to document this is a good question... How about 5.3.99? A lot of projects use this for pre-releases, but it still might make sense. Jan. -- Do you need professional PHP or Horde consulting? http://horde.org/consulting/ --- ## #47351 — Adam Harvey — 2010-03-17T09:04:49+00:00 URL: https://externals.io/message/47310#47351 · In reply to: #47350 > How about 5.3.99? A lot of projects use this for pre-releases, but it still > might make sense. I'm wary of sticking with anything starting with 5.3 if we're going to break binary compatibility on the new trunk (which we presumably are) — it undermines the usual binary compatibility guarantees on "stable" branches, even given that the new trunk is a development branch. As Johannes said: > > […] I completely agree. IMO, there's nothing wrong with calling it 5.4 now and renumbering it to 6.0/7.0/whatever (in the same manner as what Postgres are currently doing with 8.5 becoming 9.0) later if it makes sense to. Adam --- ## #47352 — Antony Dovgal — 2010-03-17T09:25:00+00:00 URL: https://externals.io/message/47310#47352 · In reply to: #47315 > > […] > > Can't see why not. Is there an RFC for this? No, there are no RFCs on that. Just copy sapi/fpm to 5_4 and you've merged it. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP --- ## #47353 — Pierre Joye — 2010-03-17T09:30:34+00:00 URL: https://externals.io/message/47310#47353 · In reply to: #47352 > > > […] > > No, there are no RFCs on that. > Just copy sapi/fpm to 5_4 and you've merged it. There is no 5.4 either, trunk is the way for now. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #47361 — Derick Rethans — 2010-03-17T15:14:57+00:00 URL: https://externals.io/message/47310#47361 · In reply to: #47335 > > […] > > Probably something like "I have this patch and I wrote this RFC, please > discuss", then wait reasonable* time for discussion and reasonable* consensus > before commit, and for reasonably* small patches "I'm going to commit it in 2 > days unless somebody objects" would work > > (*) I know definitions of "reasonable" differ but I have faith we find a > common ground. Yup, that's what I was thinking about. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #47384 — Hannes Magnusson — 2010-03-17T22:11:35+00:00 URL: https://externals.io/message/47310#47384 · In reply to: #47341 > > > > > […] > > > Is this tone really necessary? One you are argueing for more flexibility and then you are shooting the messenger because in a long list he forgot one thing (there are probably a few others .. we might want to go through the todo wiki pages for more)? > "tones" are misleading :] One of the things we already discussed before this thread was to attempt alternative ways to approach "the unicode problem". That mbstring patch is one of those ways. Its nonintrusive (well, to other parts of the language) and should be relatively backwards compatible and improves the extension quite a lot. -Hannes --- ## #47386 — Andi Gutmans — 2010-03-18T04:43:29+00:00 URL: https://externals.io/message/47310#47386 · In reply to: #47352 > -----Original Message----- > From: Antony Dovgal [mailto:tony@daylessday.org] > Sent: Wednesday, March 17, 2010 2:25 AM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 5.4 branch and trunk > > > > […] > > No, there are no RFCs on that. > Just copy sapi/fpm to 5_4 and you've merged it. I think it'd actually be a good idea to have RFCs for major pieces of new functionality even if they are retroactively written for cases such as sapi/fpm and new output buffering. Quite a bit of time has passed and it's good documentation for the new releases + gives people an opportunity to review as we work towards the next big release. It may just mean refactoring a past email that describes this in detail so doesn't have to be huge effort but would be good to be more organized with the new release. Andi --- ## #47400 — Derick Rethans — 2010-03-18T16:44:05+00:00 URL: https://externals.io/message/47310#47400 · In reply to: #47352 > > > […] > > No, there are no RFCs on that. > Just copy sapi/fpm to 5_4 and you've merged it. There is no 5_4, but still, I think there should be at least some docs on what it does, and which features and problems it addresses. Saves the doc team some work as well, and we know what we're getting ourselves into. with kind regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #47401 — Derick Rethans — 2010-03-18T16:46:22+00:00 URL: https://externals.io/message/47310#47401 > At 17:58 16/03/2010, Derick Rethans wrote: > > […] > > > +1 > > > […] > > A while ago Lukas and I prepared an alternative RFC that I'd like > people to review - now that it's becoming relevant again I'd like to > revive that discussion: http://wiki.php.net/rfc/typecheckingweak I'm aware of that. I was just listing a bunch of features. To avoid confusion, I'll start a new thread for each of them. with kind regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- Next page: https://externals.io/message/47310.md?page=2