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.
- 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 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
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 whyI 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--
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.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Em Tue, 26 Jul 2011 16:00:25 +0100, Ferenc Kovacs tyra3l@gmail.com
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/opengrok/xref/PHP_5_4/UPGRADING ), though I've noticed
not everything is there, either intentionally or unintentionally (see
https://bugs.php.net/bug.php?id=54657 ).
--
Gustavo Lopes
Em Tue, 26 Jul 2011 16:00:25 +0100, Ferenc Kovacs tyra3l@gmail.com
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/opengrok/xref/PHP_5_4/UPGRADING
), though I've noticed not everything is there, either intentionally or
unintentionally (see https://bugs.php.net/bug.php?id=54657 ).
What is missing? We must keep it updated, same for UPGRADING.INTERNALS
(which looks very outdated right now :( ).
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Em Tue, 26 Jul 2011 16:15:38 +0100, Pierre Joye pierre.php@gmail.com
escreveu:
On Tue, Jul 26, 2011 at 5:14 PM, Gustavo Lopes glopes@nebm.ist.utl.pt
wrote:Em Tue, 26 Jul 2011 16:00:25 +0100, Ferenc Kovacs tyra3l@gmail.com
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/opengrok/xref/PHP_5_4/UPGRADING
), though I've noticed not everything is there, either intentionally or
unintentionally (see https://bugs.php.net/bug.php?id=54657 ).What is missing? We must keep it updated, same for UPGRADING.INTERNALS
(which looks very outdated right now :( ).
The bug report I gave one such example. Another example from the of my
head would include closure rebinding, which has no mention at all in
UPGRADING (and which is pending the voted on changes). Traits are also
only mentioned lightly -- the new reflection functions --, but no mention
of the engine changes that cause BC breaks (e.g. now you can't have a
function named "trait").
These are just changes I know by heart, to have a more comprehensive list,
one would have to go through the commits or do a diff to 5.3. Even then,
it's not easy to sometimes evaluate the impacts of changes in the more
complex parts, e.g. in the engine.
--
Gustavo Lopes