Re: [PHP-DEV] session_* removal in 5.4

2011-07-26 Thread Gustavo Lopes
Em Tue, 26 Jul 2011 16:15:38 +0100, Pierre Joye escreveu: On Tue, Jul 26, 2011 at 5:14 PM, Gustavo Lopes wrote: Em Tue, 26 Jul 2011 16:00:25 +0100, Ferenc Kovacs escreveu: Could we get a list of the BC breaks? It would be required to get together eventually as we have to write the 5.3->

Re: [PHP-DEV] session_* removal in 5.4

2011-07-26 Thread Pierre Joye
On Tue, Jul 26, 2011 at 5:14 PM, Gustavo Lopes wrote: > Em Tue, 26 Jul 2011 16:00:25 +0100, Ferenc Kovacs > escreveu: > >> Could we get a list of the BC breaks? >> It would be required to get together eventually as we have to write >> the 5.3->5.4 migration guide as we did in the past for the pre

Re: [PHP-DEV] session_* removal in 5.4

2011-07-26 Thread Gustavo Lopes
Em Tue, 26 Jul 2011 16:00:25 +0100, Ferenc Kovacs escreveu: Could we get a list of the BC breaks? It would be required to get together eventually as we have to write the 5.3->5.4 migration guide as we did in the past for the previous versions. You can parse UPGRADING ( http://lxr.php.net

Re: [PHP-DEV] session_* removal in 5.4

2011-07-26 Thread Ferenc Kovacs
On Tue, Jul 26, 2011 at 4:57 PM, Philip Olson wrote: > > On Jul 25, 2011, at 1:57 PM, JJ wrote: > >> While looking over the release notes for 5.4a1 >> (http://www.php.net/archive/2011.php#id2011-06-28-1) I noticed that >> the related session_* functions had been removed. >> >> As I interpreted it,

Re: [PHP-DEV] session_* removal in 5.4

2011-07-26 Thread Philip Olson
On Jul 25, 2011, at 1:57 PM, JJ wrote: > While looking over the release notes for 5.4a1 > (http://www.php.net/archive/2011.php#id2011-06-28-1) I noticed that > the related session_* functions had been removed. > > As I interpreted it, this goes against the spirit of the release RFC > for x.y+1.z

[PHP-DEV] session_* removal in 5.4

2011-07-25 Thread JJ
While looking over the release notes for 5.4a1 (http://www.php.net/archive/2011.php#id2011-06-28-1) I noticed that the related session_* functions had been removed. As I interpreted it, this goes against the spirit of the release RFC for x.y+1.z releases, specifically: - Backward compatibility mu