[PHP-DEV] Code freeze for 5.4

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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,

On Sat, Jan 7, 2012 at 11:40 PM, Stas Malyshev <[email protected]> wrote:
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

ah right, thanks Patrick :)

On Sun, Jan 8, 2012 at 1:41 PM, Sebastian Bergmann <[email protected]> wrote:
> 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/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sun, Jan 8, 2012 at 12:40 AM, Stas Malyshev <[email protected]> wrote:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

hi Marius,

You can do it yourself :-)

Cheers,

On Tue, Jan 10, 2012 at 7:50 AM, marius adrian popa <[email protected]> wrote:
> On Sun, Jan 8, 2012 at 12:40 AM, Stas Malyshev <[email protected]> wrote:
>> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Sat, 07 Jan 2012 14:40:25 -0800, Stas Malyshev wrote:

> 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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

looks like a good candidate to me.

On Tue, Jan 17, 2012 at 4:41 PM, Michael Wallner <[email protected]> wrote:
> On Sat, 07 Jan 2012 14:40:25 -0800, Stas Malyshev wrote:
>
>> 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
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Go ahead and commit it please.

On 2012-01-17, Michael Wallner <[email protected]> wrote:
> On Sat, 07 Jan 2012 14:40:25 -0800, Stas Malyshev wrote:
>
>> 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
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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 <[email protected]>:
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

I added a patch to bug #60809. If it's ok I can commit it.

Pierrick

On 19 January 2012 20:55, Stas Malyshev <[email protected]> wrote:
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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 <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi Stats,


2012/1/20 Stas Malyshev <[email protected]>:
> 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:

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().

>
>
>> 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.

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi Stats,

2012/1/20 Stas Malyshev <[email protected]>:
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php