Hi,
Just reading the excellent PHP 5.5 Upgrades Notes -
https://raw.github.com/php/php-src/php-5.5.0beta1/UPGRADING
Some questions:
-
Dropped support for Windows XP & 2003:
o Was this an RFC? At what point was it decided? (I may have missed it in
that case I’d just appreciate a pointer to where it was decided). I am
asking because XP still seems to be quite prevalent and while Microsoft
wants to incentivize people to upgrade by being aggressive around end of
life, not sure that’s the most convenient for our users.
-
In “Backwards Incompatible Changes” there’s a big list of BC
changes that are internals and don’t impact user land. So could come across
a lot more intimidating than it is. I think we should move towards the end
of the upgrade notes in a section of its own that’s “PHP Internals Changes
– does not impact user space” (or something of that sort). I’m happy to
make that change but wanted to bring it up before tackling it.
-
On similar note as previous item, should we put New Features
before BC changes? No big deal but it’s always nice to have the more
positive piece first :)
Andi
hi,
Some questions:
Dropped support for Windows XP & 2003:o Was this an RFC? At what point was it decided? (I may have missed it in
that case I’d just appreciate a pointer to where it was decided). I am
asking because XP still seems to be quite prevalent and while Microsoft
wants to incentivize people to upgrade by being aggressive around end of
life, not sure that’s the most convenient for our users.
It was announced with 5.4.0, 5.4.0 was the last release to support
Windows XP/2003. Which were already not supported anymore back then.
In “Backwards Incompatible Changes” there’s a big list of BCchanges that are internals and don’t impact user land. So could come across
a lot more intimidating than it is. I think we should move towards the end
of the upgrade notes in a section of its own that’s “PHP Internals Changes
– does not impact user space” (or something of that sort). I’m happy to
make that change but wanted to bring it up before tackling it.
Sounds good, also if they are internals changes, they should be part
of UPGRADING.INTERNALS, which cruelly needs love:
https://github.com/php/php-src/blob/master/UPGRADING.INTERNALS
On similar note as previous item, should we put New Featuresbefore BC changes? No big deal but it’s always nice to have the more
positive piece first :)
Sounds good too, however I have to check which BC changes are in
there, as we are not supposed to allow any :) (except bugs fixes for
bad/undocumented/random behavior as usual).
Cheers,
Pierre
@pierrejoye
Hi!
In “Backwards Incompatible Changes” there’s a big list of BCchanges that are internals and don’t impact user land. So could come across
a lot more intimidating than it is. I think we should move towards the end
of the upgrade notes in a section of its own that’s “PHP Internals Changes
– does not impact user space” (or something of that sort). I’m happy to
make that change but wanted to bring it up before tackling it.
Definitely should be moved to UPGRADING.INTERNALS - all after "Removal
of Logo GUIDs".
On similar note as previous item, should we put New Featuresbefore BC changes? No big deal but it’s always nice to have the more
positive piece first :)
I know I'd look into BC stuff first, because that's the more scary part
of the upgrade. But either way is fine :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227