# Code freeze for 5.4 - Thread: https://externals.io/message/57266 - Original archive: https://news-web.php.net/php.internals/57266 - Started by Stas Malyshev on 2012-01-07T22:40:25+00:00 - Messages: 17 - 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 --- ## #57266 — Stas Malyshev — 2012-01-07T22:40:25+00:00 URL: https://externals.io/message/57266#57266 Hi! As we are nearing the release of 5.4.0, I'd like to ask everybody not to commit anything to 5.4 branch without the approval of one of the RMs (myself or David) from now until release of 5.4.0. Unless something critical for 5.4.0 is found, we'd like RC6 (planned on Jan 19) to be the final RC and the code which we release. The following may be considered for inclusion: - Unit tests & test fixes - Fixes for critical bugs - Security fixes - BC break fixes Please still ask RMs for approval prior to committing even if your patch falls into these categories. Commits to trunk are OK. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #57268 — Pierre Joye — 2012-01-08T12:37:24+00:00 URL: https://externals.io/message/57266#57268 · In reply to: #57266 hi David, Stas, As far as I know, the only BC so far is the request time float addition to restore the previous behavior. I will do it this afternoon if nobody catches up with it before :) Cheers, > Hi! > > As we are nearing the release of 5.4.0, I'd like to ask everybody not to > commit anything to 5.4 branch without the approval of one of the RMs (myself > or David) from now until release of 5.4.0. Unless something critical for > 5.4.0 is found, we'd like RC6 (planned on Jan 19) to be the final RC and the > code which we release. > > The following may be considered for inclusion: > - Unit tests & test fixes > - Fixes for critical bugs > - Security fixes > - BC break fixes > Please still ask RMs for approval prior to committing even if your patch > falls into these categories. > > Commits to trunk are OK. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57269 — Sebastian Bergmann — 2012-01-08T12:41:36+00:00 URL: https://externals.io/message/57266#57269 · In reply to: #57268 Am 08.01.2012 13:37, schrieb Pierre Joye: > As far as I know, the only BC so far is the request time float > addition to restore the previous behavior. I will do it this afternoon > if nobody catches up with it before :) That was already restored (in r321828). -- Sebastian Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #57270 — Pierre Joye — 2012-01-08T12:47:53+00:00 URL: https://externals.io/message/57266#57270 · In reply to: #57269 ah right, thanks Patrick :) > Am 08.01.2012 13:37, schrieb Pierre Joye: > > […] > >  That was already restored (in r321828). > > -- > Sebastian Bergmann                    Co-Founder and Principal Consultant > http://sebastian-bergmann.de/                           http://thePHP.cc/ > > -- > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57317 — marius adrian popa — 2012-01-10T06:50:14+00:00 URL: https://externals.io/message/57266#57317 · In reply to: #57266 > Hi! > > As we are nearing the release of 5.4.0, I'd like to ask everybody not to > commit anything to 5.4 branch without the approval of one of the RMs (myself > or David) from now until release of 5.4.0. Unless something critical for > 5.4.0 is found, we'd like RC6 (planned on Jan 19) to be the final RC and the > code which we release. > > The following may be considered for inclusion: > - Unit tests & test fixes > - Fixes for critical bugs > - Security fixes > - BC break fixes > Please still ask RMs for approval prior to committing even if your patch > falls into these categories. Could you add to the NEWS - Pdo Firebird: . Fixed bug #47415 (PDO_Firebird segfaults when passing lowercased column name to bindColumn). . Fixed bug #53280 (PDO_Firebird segfaults if query column count less than param count). (Mariuz) Thanks --- ## #57318 — Pierre Joye — 2012-01-10T07:09:13+00:00 URL: https://externals.io/message/57266#57318 · In reply to: #57317 hi Marius, You can do it yourself :-) Cheers, > > > […] > > Could you add to the NEWS > - Pdo Firebird: >  . Fixed bug #47415 (PDO_Firebird segfaults when passing lowercased > column name to bindColumn). >  . Fixed bug #53280 (PDO_Firebird segfaults if query column count > less than param count). >    (Mariuz) > > Thanks > > -- > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57399 — Michael Wallner — 2012-01-17T15:41:50+00:00 URL: https://externals.io/message/57266#57399 · In reply to: #57266 > The following may be considered for inclusion: > - Unit tests & test fixes - Fixes for critical bugs - Security fixes - > BC break fixes Please still ask RMs for approval prior to committing > even if your patch falls into these categories. > > Commits to trunk are OK. Is https://bugs.php.net/60221 considerable for inclusion? It's kind of a BC break. The fix has already been comitted to trunk. Mike --- ## #57400 — Pierre Joye — 2012-01-17T17:00:47+00:00 URL: https://externals.io/message/57266#57400 · In reply to: #57399 looks like a good candidate to me. > > > > […] > > Is https://bugs.php.net/60221 considerable for inclusion? > It's kind of a BC break.  The fix has already been comitted to trunk. > > Mike > > > -- > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57401 — David Soria Parra — 2012-01-17T20:44:37+00:00 URL: https://externals.io/message/57266#57401 · In reply to: #57399 Go ahead and commit it please. > > > > […] > > Is https://bugs.php.net/60221 considerable for inclusion? > It's kind of a BC break. The fix has already been comitted to trunk. > > Mike --- ## #57442 — Yasuo Ohgaki — 2012-01-20T01:45:23+00:00 URL: https://externals.io/message/57266#57442 · In reply to: #57266 Hi Stats, I would like to commit session adaption patch to 5.4, since it does not change current session module behavior by default and affected application can be protected by changing php.ini setting. As you already know, it requires structure changes and it would be binary incompatible if add it later. If there is no objections, I'll commit it to both trunk and 5.4. For PHP 5.3, we can modify patch so that it does not require module structure changes, but I don't have spare time to do that now. PHP 5.3 users may user land (user script base) solution still. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net 2012/1/8 Stas Malyshev : > Hi! > > As we are nearing the release of 5.4.0, I'd like to ask everybody not to > commit anything to 5.4 branch without the approval of one of the RMs (myself > or David) from now until release of 5.4.0. Unless something critical for > 5.4.0 is found, we'd like RC6 (planned on Jan 19) to be the final RC and the > code which we release. > > The following may be considered for inclusion: > - Unit tests & test fixes > - Fixes for critical bugs > - Security fixes > - BC break fixes > Please still ask RMs for approval prior to committing even if your patch > falls into these categories. > > Commits to trunk are OK. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #57443 — Stas Malyshev — 2012-01-20T01:55:49+00:00 URL: https://externals.io/message/57266#57443 · In reply to: #57442 Hi! > I would like to commit session adaption patch to 5.4, since it > does not change current session module behavior by default > and affected application can be protected by changing php.ini > setting. As you already know, it requires structure changes and > it would be binary incompatible if add it later. I feel such a big patch would without doubt require another RC and thus delay release of 5.4.0 by at least 2 weeks. So unless this patch is perceived as required by the community I would advise to not commit it to 5.4 now. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #57444 — Pierrick Charron — 2012-01-20T02:25:02+00:00 URL: https://externals.io/message/57266#57444 · In reply to: #57443 I added a patch to bug #60809. If it's ok I can commit it. Pierrick > Hi! > > > > […] > > > I feel such a big patch would without doubt require another RC and thus > delay release of 5.4.0 by at least 2 weeks. So unless this patch is > perceived as required by the community I would advise to not commit it to > 5.4 now. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #57446 — Yasuo Ohgaki — 2012-01-20T03:08:00+00:00 URL: https://externals.io/message/57266#57446 · In reply to: #57443 Hi Stats, Ok, I'll hold committing to 5.4, but commit it only to trunk. Any comments form anyone? for committing to trunk? Patch details and user land counter measure are in RFC. https://wiki.php.net/rfc/strict_sessions BTW, if we hold this patch, I think we should write patch that does not touch PS module structure for PHP 5.4, too. In this case, users cannot distinguish whether PS module is adoptive or not. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net 2012/1/20 Stas Malyshev : > Hi! > > > > […] > > > I feel such a big patch would without doubt require another RC and thus > delay release of 5.4.0 by at least 2 weeks. So unless this patch is > perceived as required by the community I would advise to not commit it to > 5.4 now. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #57453 — Stas Malyshev — 2012-01-20T07:07:55+00:00 URL: https://externals.io/message/57266#57453 · In reply to: #57446 Hi! > Hi Stats, > > Ok, I'll hold committing to 5.4, but commit it only to trunk. > > Any comments form anyone? for committing to trunk? > Patch details and user land counter measure are in RFC. Re-reading the discussion, I see that the question of why we need separate validator handler is still unresolved. I think we were left with this: > In this case, users cannot distinguish whether PS module is adoptive or not. But this can be solved by documentation, unless you mean "users in the code" - but then I don't see how having new handler would help as PHP code can not really check for this handler, can it? So the question why we need such handler is still open. However if we would have binary compatible patch it probably would be ok for 5.4.1. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #57456 — Yasuo Ohgaki — 2012-01-20T08:23:42+00:00 URL: https://externals.io/message/57266#57456 · In reply to: #57453 Hi Stats, 2012/1/20 Stas Malyshev : > Hi! > > > > […] > > > Re-reading the discussion, I see that the question of why we need separate > validator handler is still unresolved. I think we were left with this: It's for reduced complexity. With separate validation function, we can - reduce PS module writer's choice whether validation belong to PS_OPEN_FUNC() or PS_READ_FUNC() session data. Validation always belongs to PS_VALIDATE_SID_FUNC(). - inform user save handler (PHP script save handler) writers that they are responsible to validate session ID. We can make new session ID in PS_OPEN_FUNC() or PS_READ_FUNC() always when ID is not already initialized one, by calling private validation function from PS_OPEN_FUNC() or PS_READ_FUNC(). However, I think it's more cleaner to keep PS module's modular architecture. Current session module's code is complex enough. Not many people would understand the logic at a glance. New PS module writers should always write SID validation function. Separate API is easier for most people, I suppose. However, if you insist, I'm ok to modify patch so that it validates session ID in PS_READ_FUNC(). > > > > […] > > > But this can be solved by documentation, unless you mean "users in the code" > - but then I don't see how having new handler would help as PHP code can not > really check for this handler, can it? So the question why we need such > handler is still open. > However if we would have binary compatible patch it probably would be ok for > 5.4.1. Choice is yours. If it's ok to add structure members that requires current patch, I'll commit new module structure now. And I'll commit the rest for 5.4.1. If you prefer to maintain current structure/API, I'll modify patch. I would like to add strict session to PHP 5.3, so I have to do that anyway for binary compatibility. Regards, -- Yasuo Ohgaki --- ## #57457 — Stas Malyshev — 2012-01-20T08:49:42+00:00 URL: https://externals.io/message/57266#57457 · In reply to: #57456 Hi! > We can make new session ID in PS_OPEN_FUNC() or PS_READ_FUNC() always > when ID is not already initialized one, by calling private validation > function from > PS_OPEN_FUNC() or PS_READ_FUNC(). However, I think it's more cleaner to > keep PS module's modular architecture. > > Current session module's code is complex enough. Not many people would > understand > the logic at a glance. New PS module writers should always write SID validation > function. Separate API is easier for most people, I suppose. I think calling one function wouldn't add that much and can be clearly commented if something is not clear enough from the code. > If it's ok to add structure members that requires current patch, > I'll commit new module structure now. And I'll commit the rest > for 5.4.1. No, please don't commit anything in 5.4. I don't want any large changes now. > If you prefer to maintain current structure/API, I'll modify patch. > I would like to add strict session to PHP 5.3, so I have to do that anyway > for binary compatibility. I'd propose to make a binary-compatible change for 5.3 and 5.4.1, and discuss what we do for trunk - I still like the idea of keeping less handlers better, and if that means we can have the same patch for all branches, then it's an added bonus. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #57459 — Yasuo Ohgaki — 2012-01-20T09:44:12+00:00 URL: https://externals.io/message/57266#57459 · In reply to: #57457 Hi Stats, 2012/1/20 Stas Malyshev : > I'd propose to make a binary-compatible change for 5.3 and 5.4.1, and > discuss what we do for trunk - I still like the idea of keeping less > handlers better, and if that means we can have the same patch for all > branches, then it's an added bonus. Ok, then I'll modify patch so that it validates session ID within PS_READ_FUNC(). We have to provide good documentation that explains user save handler and PS module require session ID validation by their own. I'll work for it after 5.4.0 release. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net