Re: session_* removal in 5.4
| From: | Philip Olson | Date: | Tue, 26 Jul 2011 14:57:08 +0000 |
| Subject: | Re: session_* removal in 5.4 | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-54210@lists.php.net to get a copy of this message | ||
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 releases, specifically:
>
> - Backward compatibility must be kept
> - API compatibility must be kept (user land)
>
> The removal of these functions makes sense (to me) but I think in
> order to respect the release RFC we should either:
>
> a) defer the removal of session_* functions till the appropriate release
> b) update the RFC nomeclature to cover this use case (as Florian
> pointed out, the current wording leaves it open to interpretation)
>
> I do realize I'm late to the party (sorry) and I'm not sure if it's
> too late to revert course on this specific change...but I think the
> session_* removal change will make the upgrade process more difficult
> because of its' far-reaching impact.
In reality, PHP 5.4 does not follow the aforementioned release RFC as it
breaks a lot of BC. It follows part of it, but certainly not all.
If the session_* functions are restored due to BC, then a lot of other
old stuff will need to follow along. Here are a few options:
(A) Rename 5.4 to 6.0 ... :)
(B) Remove all BC breaking changes from 5.4
(C) Change the release RFC (addendum?)
(D) Mention that 5.4 does not fully follow the release RFC, and why
I suspect a version of (D) will be implemented at this point, and 5.4
kinda sorta existed before the RFC. A difficult decision.
Regards,
Philip