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
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
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/
ah right, thanks Patrick :)
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/--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
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
hi Marius,
You can do it yourself :-)
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.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
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
looks like a good candidate to me.
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
--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Go ahead and commit it please.
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
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 smalyshev@sugarcrm.com:
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
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
I added a patch to bug #60809. If it's ok I can commit it.
Pierrick
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
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 smalyshev@sugarcrm.com:
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
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
Hi Stats,
2012/1/20 Stas Malyshev smalyshev@sugarcrm.com:
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
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
Hi Stats,
2012/1/20 Stas Malyshev smalyshev@sugarcrm.com:
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