Hi,
So, if we are talking about PHP 6, then the opening <?php tag should be
accompanied by the version it was written for, it was tested with and then
the engine could switch to a compatibility mode for that version.
Seems to me that this would solve the problem where a host can't upgrade to
a more modern version for fear of breaking old code. Consequently, open
source packages -- like Drupal I am deeply involved with -- can't use more
modern PHP versions decreasing the "push" for hosts to upgrade. This is a
devilish circle and it'd be great to break it.
Regards,
Karoly Negyesi
hi,
Hi,
So, if we are talking about PHP 6, then the opening <?php tag should be
accompanied by the version it was written for, it was tested with and then
the engine could switch to a compatibility mode for that version.Seems to me that this would solve the problem where a host can't upgrade to
a more modern version for fear of breaking old code. Consequently, open
source packages -- like Drupal I am deeply involved with -- can't use more
modern PHP versions decreasing the "push" for hosts to upgrade. This is a
devilish circle and it'd be great to break it.
We have been there, no chance to go back again with such tags.
Also the new release process RFC
(https://wiki.php.net/rfc/releaseprocess) solves the BC issues between
minor updates (5.4 to 5.5, or 5.3 to 5.4 f.e.). It is our and our
users role to explain that to their ISPs, admins, etc.
Cheers,
Pierre
@pierrejoye
Well, either I misunderstood the policy or it's broken. Here are some
(note: please do not argue whether these are more correct than before,
they very well might be but they broke backwards compatibility):
For example, in 5.4 array_diff_assoc began to throw a notice when
casting to string.
Again in 5.4, using a string offset against a string throws a warning.
It wasn't doing that before.
If you want I can dig around in our issue queue for more backwards
compatibility breaks but there are some.
Regards,
Karoly Negyesi
hi,
Hi,
So, if we are talking about PHP 6, then the opening <?php tag should be
accompanied by the version it was written for, it was tested with and then
the engine could switch to a compatibility mode for that version.Seems to me that this would solve the problem where a host can't upgrade to
a more modern version for fear of breaking old code. Consequently, open
source packages -- like Drupal I am deeply involved with -- can't use more
modern PHP versions decreasing the "push" for hosts to upgrade. This is a
devilish circle and it'd be great to break it.We have been there, no chance to go back again with such tags.
Also the new release process RFC
(https://wiki.php.net/rfc/releaseprocess) solves the BC issues between
minor updates (5.4 to 5.5, or 5.3 to 5.4 f.e.). It is our and our
users role to explain that to their ISPs, admins, etc.Cheers,
Pierre
@pierrejoye
Well, either I misunderstood the policy or it's broken. Here are some
(note: please do not argue whether these are more correct than before,
they very well might be but they broke backwards compatibility):For example, in 5.4 array_diff_assoc began to throw a notice when
casting to string.Again in 5.4, using a string offset against a string throws a warning.
It wasn't doing that before.
We do not consider a change in warnings/notices a BC break. I realize
for certain test frameworks and custom error handlers it could break
things if they are expecting a specific warning or lack of warning, but
the code itself behaves exactly as it did before and as such there is no
BC break.
-Rasmus
Well, either I misunderstood the policy or it's broken. Here are some
(note: please do not argue whether these are more correct than before,
they very well might be but they broke backwards compatibility):For example, in 5.4 array_diff_assoc began to throw a notice when
casting to string.Again in 5.4, using a string offset against a string throws a warning.
It wasn't doing that before.We do not consider a change in warnings/notices a BC break. I realize
for certain test frameworks and custom error handlers it could break
things if they are expecting a specific warning or lack of warning, but
the code itself behaves exactly as it did before and as such there is no
BC break.
I for one think this point needs to be communicated a lot more clearly,
because when I attempted to introduce a patch that would throw E_DEPRECATED
warning for mcrypt last year I was told it could not be merged in 5.4 since
it would cause a BC break. Later someone else disagreed with that. So
clearly not everyone seems to be inline.
</my two cents>
-Rasmus
We do not consider a change [...] a BC break
Let me help: backwards compatibility means a host can upgrade a
package without inducing a lot of support tickets.
Best,
Karoly Negyesi
We do not consider a change [...] a BC break
Let me help: backwards compatibility means a host can upgrade a
package without inducing a lot of support tickets.
Well, that is obviously not realistic. Every change we make has some
level of BC impact. We have to draw a line somewhere. Heck, even fixing
a segfault is technically a BC change because the behaviour from one
version to the next is different. A 100% strict "no BC" rule would mean
we couldn't actually ever fix any bugs. There has to be a line. Our line
is that in minor version upgrades we won't change documented functional
behaviour unless there are extremely serious (usually security-related)
reasons for doing so.
-Rasmus
Well, fixing a segfault, adding a new function or method as it oft
happened in PHP 5.3 is only breaking forwards compatibility not
backwards -- if you have code that ran on PHP 5.3.4 it'll run on
5.3.5. The reverse is not true which causes some headaches to Drupal
developers but it's not relevant to this discussion.
So, what about adding a version string to the opening <?php tag so
that you can fix bugs while not breaking BC :P ?
We do not consider a change [...] a BC break
Let me help: backwards compatibility means a host can upgrade a
package without inducing a lot of support tickets.Well, that is obviously not realistic. Every change we make has some
level of BC impact. We have to draw a line somewhere. Heck, even fixing
a segfault is technically a BC change because the behaviour from one
version to the next is different. A 100% strict "no BC" rule would mean
we couldn't actually ever fix any bugs. There has to be a line. Our line
is that in minor version upgrades we won't change documented functional
behaviour unless there are extremely serious (usually security-related)
reasons for doing so.-Rasmus
Well, fixing a segfault, adding a new function or method as it oft
happened in PHP 5.3 is only breaking forwards compatibility not
backwards -- if you have code that ran on PHP 5.3.4 it'll run on
5.3.5. The reverse is not true which causes some headaches to Drupal
developers but it's not relevant to this discussion.So, what about adding a version string to the opening <?php tag so
that you can fix bugs while not breaking BC :P ?
We had that in the past and it was a mess. We are not going to make that
mistake again.
-Rasmus
If you mean <?php3 then well, I was not here but maybe we could learn
from the mistakes and get a better implementation? I have some ideas,
but first I'd be glad to learn why it was a mess.
Well, fixing a segfault, adding a new function or method as it oft
happened in PHP 5.3 is only breaking forwards compatibility not
backwards -- if you have code that ran on PHP 5.3.4 it'll run on
5.3.5. The reverse is not true which causes some headaches to Drupal
developers but it's not relevant to this discussion.So, what about adding a version string to the opening <?php tag so
that you can fix bugs while not breaking BC :P ?We had that in the past and it was a mess. We are not going to make that
mistake again.-Rasmus
If you mean <?php3 then well, I was not here but maybe we could learn
from the mistakes and get a better implementation? I have some ideas,
but first I'd be glad to learn why it was a mess.
The whole concept of maintaining multiple personalities in the same
codebase is a complete non-starter. The complexity that leads to is
mindnumbing. There really isn't anything to discuss along these lines.
It will not happen.
-Rasmus
We do not consider a change [...] a BC break
Let me help: backwards compatibility means a host can upgrade a
package without inducing a lot of support tickets.Best,
Karoly Negyesi
--
As Rasmus already pointed out, 100% backwards compatibility is simply
unrealistic. You would also be hard-pressed to find any scripting language
out there that puts as much focus on maintaining BC as PHP does.
Personally, I think we worry about it a little too much when it comes to
major version changes.
If you write your code to be scalable and have at least some sliver of
forward compatibility, then minor changes like notices and warnings should
not cause your codebase to blow up in your face. If they are causing that
and fixing it would require "a lot of support tickets," as you put it, then
I think the problem is with your code, not PHP. You should always
anticipate possible changes in the language when writing your code if you
plan on upgrading to the latest versions of the language.
There is a simple solution for maintaining 100% BC: Don't upgrade PHP.
Same goes for Perl, Python, Java, etc. If your code isn't forward
compatible, just target it to the version it was written for and you're
good to go. If you want people to be able to upgrade PHP, then you have to
do your part by making your code scalable at least to a reasonable degree.
I think we already do more than our part with how careful we are about
behavioral changes in minor version increments.
I also agree that different tags for different versions is just impractical
and represents a maintenance nightmare. But if you really want to go
forward with your suggestion, write an RFC to be voted on. I'd be happy to
publish it to the wiki on your behalf, though I won't be voting for it.
--Kris
OK, let's try this again.
Maybe language versioning is out. That's sad, but this thread brought
to light a much more important problem I would like to try to address.
I have long felt the PHP team is living in another world I do.
Let me describe my world. I am working on an open source package. So
does another 1000 or so developers. And another 10 000 adds modules
(or maybe you'd call them plugins). I do not even know how many then
adds custom, site specific code. This whole pile of software forms an
ecosystem which is quite sizeable. The software is somewhat popular.
Users form a pyramid. The bottom is shared hosts. Shared hosts that we
need to take into consideration. So if the shared world just barely
switched to 5.3 default then, alas, we can't release a version that
requires PHP 5.4 because there is no shared support for it. Also, it
worths mentioning that one of the more popular server OSes, Ubuntu LTS
also doesn't have a PHP 5.4 yet. Without software demanding 5.4, hosts
won't upgrade. This is a vicious circle that is superb hard to break.
I was told in this thread that the new release process solves this and
"it is our and our users role to explain that to their ISPs, admins,
etc".
Well, what am I to explain? As I mentioned previously, if a shared
host does a PHP upgrade and their users see new error messages, then
the host have a support problem. When I tried to point this out, I got
strawman arguments (about segfaults and bugfixes which breaking
forward compatibility and absolutely having nothing to do with BC) and
ridicule ("the problem is with your code"). You can ridicule the
codebase all you want, but the codebase a) works b) tested. This
doesn't change the fact that breaking backwards compatibility a little
is like being a little pregnant. Either you are or you are not and
currently you are not. This is sad because apparently a lot of work is
being put into this and then on a minor point it falls short of the
goal.
It would make everyone's life so much easier if all the Drupal 8 code
that is being written and tested with 5.4 would just work 5.5 without
any problem.
I would absolutely love not to have this conversation again three
years from now when we need to decide to ship Drupal 9 with PHP 5.5 or
5.4 -- because we could indeed do a campaign when 5.4 is due to change
to 5.5 outright because it won't break BC with 5.4. Is this absolutely
unattainable?
Best regards
Karoly Negyesi
OK, let's try this again.
Maybe language versioning is out. That's sad, but this thread brought
to light a much more important problem I would like to try to address.I have long felt the PHP team is living in another world I do.
Let me describe my world. I am working on an open source package. So
does another 1000 or so developers. And another 10 000 adds modules
(or maybe you'd call them plugins). I do not even know how many then
adds custom, site specific code. This whole pile of software forms an
ecosystem which is quite sizeable. The software is somewhat popular.Users form a pyramid. The bottom is shared hosts. Shared hosts that we
need to take into consideration. So if the shared world just barely
switched to 5.3 default then, alas, we can't release a version that
requires PHP 5.4 because there is no shared support for it. Also, it
worths mentioning that one of the more popular server OSes, Ubuntu LTS
also doesn't have a PHP 5.4 yet. Without software demanding 5.4, hosts
won't upgrade. This is a vicious circle that is superb hard to break.I was told in this thread that the new release process solves this and
"it is our and our users role to explain that to their ISPs, admins,
etc".Well, what am I to explain? As I mentioned previously, if a shared
host does a PHP upgrade and their users see new error messages, then
the host have a support problem. When I tried to point this out, I got
strawman arguments (about segfaults and bugfixes which breaking
forward compatibility and absolutely having nothing to do with BC) and
ridicule ("the problem is with your code"). You can ridicule the
codebase all you want, but the codebase a) works b) tested. This
doesn't change the fact that breaking backwards compatibility a little
is like being a little pregnant. Either you are or you are not and
currently you are not. This is sad because apparently a lot of work is
being put into this and then on a minor point it falls short of the
goal.It would make everyone's life so much easier if all the Drupal 8 code
that is being written and tested with 5.4 would just work 5.5 without
any problem.
Yup, so please test it against 5.5 now. Have you done so? It is rather
trivial to do. Grab it from git or there is a tarball at http://qa.php.net
I would absolutely love not to have this conversation again three
years from now when we need to decide to ship Drupal 9 with PHP 5.5 or
5.4 -- because we could indeed do a campaign when 5.4 is due to change
to 5.5 outright because it won't break BC with 5.4. Is this absolutely
unattainable?
Yes, I would say it is unattainable. You are essentially asking that we
don't make any changes. Nothing that could possibly affect existing code
down to and including any potential warning messages even if that code
is obviously incorrect, insecure and/or not doing what the developer
intended. That means no new keywords, no new notices, no bug fixes. What
exactly can we do in a new version then?
Just as a point of reference, the array to string conversion notice that
was added in 5.4, which seems to be at the center of your argument, has
found 6 potential bugs across 3 different companies I work closely with.
This was a good and useful change to a large part of our userbase. You
should also recognize that there is also a large faction that wants to
see us make even more drastic changes along these lines and not less. We
have to try to balance both ends of this spectrum.
-Rasmus
I don't see the problem for a software with this minor BC breaks from 5.3
to 5.5.
The biggest change ever happened with namespaces and so in in 5.3 should
already be done.
If you have to change some parts, this is done in a few hours/days, with
search and replace and a little bit handwork.
And for the good feeling after refactoring, there are UnitTests around
today.
Rasmus Lerdorf wrote:
It would make everyone's life so much easier if all the Drupal 8 code
that is being written and tested with 5.4 would just work 5.5 without
any problem.
Yup, so please test it against 5.5 now. Have you done so? It is rather
trivial to do. Grab it from git or there is a tarball athttp://qa.php.net
Perhaps when I've finished the time machine ...
In reality we have to make choices where we DO spend time. There is still a mile
of code out there being used live which is running perfectly on the PHP5.2
infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4
before we get around to 5.5.
This is perhaps the main problem with accelerating the release timetable in that
there simply is not enough time to bring everybody along? So something has to
give and at the moment for me it's going to have to be 5.5 ... but by the time
all the legacy stuff is up to 5.4 you will be way off in the distance :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 05.02.2013 09:14, schrieb Lester Caine:
f code out there being used live which is running perfectly on the
PHP5.2 infrastructure. That needs testing and reworking on PHP5.3
and then PHP5.4 before we get around to 5.5.This is perhaps the main problem with accelerating the release
timetable in that there simply is not enough time to bring
everybody along? So something has to give and at the moment for me
it's going to have to be 5.5 ... but by the time all the legacy
stuff is up to 5.4 you will be way off in the distance :(
Actually, it doesn't matter. Three years worth of changes are just the
same, be it in one or three versions. With faster and less radical
steps, there is a better chance the provider's upgrade cycle fits
PHP's upgrade cycle and just misses by one or two minor changesets
rather than one big. It also makes "make the site work again" a more
regular, but easier task and increases customers' awareness that
unmaintained web software will not continue to run indefinately. Just
as putting your legacy DOS app onto a new computer after the 15 year
old legacy system finally broke down will require some brains to "make
work again".
As a supporter / hired external consultant I would like that.
Ralf Lang
Linux Consultant / Developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlEQ6/UACgkQCs1dsHJ/X7Dp+QCg0prN0juyUojOuJRJ5GM1TwdS
sr8An28l0a18Idsfh6kw/8xPZ8cQwrJH
=65H6
-----END PGP SIGNATURE
----- Ursprüngliche Message -----
Von: Lester Caine lester@lsces.co.uk
An: "internals@lists.php.net" internals@lists.php.net
CC:
Gesendet: 9:14 Dienstag, 5.Februar 2013
Betreff: Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioningRasmus Lerdorf wrote:
It would make everyone's life so much easier if all the Drupal 8
codethat is being written and tested with 5.4 would just work 5.5
without
any problem.
Yup, so please test it against 5.5 now. Have you done so? It is rather
trivial to do. Grab it from git or there is a tarball athttp://qa.php.netPerhaps when I've finished the time machine ...
In reality we have to make choices where we DO spend time. There is still a mile
of code out there being used live which is running perfectly on the PHP5.2
infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4
before we get around to 5.5.
Why do you change the infrastructure if the code does not need it? I mean, provide the infrastructure the code needs and done. There is more than one vendor that offers support for PHP 5.2 infrastructure in the market. What's the deal?
This is perhaps the main problem with accelerating the release timetable in that
there simply is not enough time to bring everybody along? So something has to
give and at the moment for me it's going to have to be 5.5 ... but by the
time all the legacy stuff is up to 5.4 you will be way off in the distance :(
There was no acceleration in the release timetable from my point of view. The whole show was stopped between PHP 5.2 and 5.3. This has been fixed now by explicitly having the one-year rhythm for major releases again - documented publicly for the first time in PHP history (IRC). I like the idea to know that a new major is scheduled for the first of march. The equinox, can't you feel it? Would be great to know we get PHP 5.6 shipped until the next solar eclipse.
Also these yearly release period (the Rhythm) does not mean that it accelerated. It just helps you (and everybody else) with dancing, coordinating and planning. E.g. you can choose your speed by explicitly for example by leaving one major version out (skipping it) because you know when you can expect the next major release - thanks to rhythm - as well as you know how long it will be supported by the project.
When we got rhythm I can call my jamaican guy while being a slave to it. Grace Jones knew that. It's all leisure, no stress. The PHP userbase just grew too large you can find a solution for everyone. Having a clear release rhythm still helps everyone and looks like an appropriate tool to me.
And yeah, code, you need to refactor, always. We can't change that, nobody can. PHP might have made us lazy, which is fine, however, time goes by. Just some weeks ago I killed one of my PHP 5 babies (and it could have run even longer technically, despite the PHP releases since it saw light of day). The whole application is not needed any longer (thanks to the great improvements we have with frameworks and libraries since PHP 5.3 and 5.4). Don't work against the community, try to find good solutions of which everybody can benefit. Sure we all have issues, but the key point is to be flexible with the solutions. Be it just taking the releases of PHP 5.2 supported by third-party vendors or keeping up with the later stable leaving a time-window of three years to switch between one PHP version to the other. Additionally if even this time-frame does not work out for more than one version change, you can even skip up to two major versions to keep up with the
rest of the gang to latest. I think it was never that easy as it is today.
-- hakre
hakre wrote:
In reality we have to make choices where we DO spend time. There is still a mile
of code out there being used live which is running perfectly on the PHP5.2
infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4
before we get around to 5.5.
Why do you change the infrastructure if the code does not need it? I mean, provide the infrastructure the code needs and done. There is more than one vendor that offers support for PHP 5.2 infrastructure in the market. What's the deal?
The point here is supporting customers that I've 'acquired' who are currently
hosted on services that control that infrastructure. The long term aim is to
move them to servers under our control, but in the meantime until contracts run
out we have to live with such activity as 'We will be updating to PHP5.3 on the
1st April'. The problem now is how to deal with that situation, and paying up
outstanding contracts may be the solution. The code needs updating, and updating
to 5.4 would be useful, but short term everything needs testing and fixing for
PHP5.3 :(
The whole reason that ISP's are currently moving from PHP5.2 to PHP5.3 rather
than PHP5.4 is that there is a better chance that their client sites will
continue to work.
http://w3techs.com/technologies/history_details/pl-php/5 use of PHP5.1 is
slowing faster than 5.4 use is growing.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
----- Ursprüngliche Message -----
Von: Lester Caine lester@lsces.co.uk
An: "internals@lists.php.net" internals@lists.php.net
CC:
Gesendet: 13:42 Dienstag, 5.Februar 2013
Betreff: Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioninghakre wrote:
In reality we have to make choices where we DO spend time. There is
still a mileof code out there being used live which is running perfectly on the
PHP5.2
infrastructure. That needs testing and reworking on PHP5.3 and then
PHP5.4
before we get around to 5.5.
Why do you change the infrastructure if the code does not need it? I mean,
provide the infrastructure the code needs and done. There is more than one
vendor that offers support for PHP 5.2 infrastructure in the market. What's
the deal?The point here is supporting customers that I've 'acquired' who are
currently hosted on services that control that infrastructure. The long term aim
is to move them to servers under our control, but in the meantime until
contracts run out we have to live with such activity as 'We will be updating
to PHP5.3 on the 1st April'. The problem now is how to deal with that
situation, and paying up outstanding contracts may be the solution. The code
needs updating, and updating to 5.4 would be useful, but short term everything
needs testing and fixing for PHP5.3 :(
This might be starting to become slightly off-topic for the list, but what prevents you from communicating the problem to your customers and also offering them the help they need?
The whole reason that ISP's are currently moving from PHP5.2 to PHP5.3
rather than PHP5.4 is that there is a better chance that their client sites will
continue to work.
I can not say that for the ISPs I use and I've been talking to. For the handmade ones it's more what their distro offers, for the commercially professional ones it's more what their users ask for.
http://w3techs.com/technologies/history_details/pl-php/5 use of PHP5.1 is
slowing faster than 5.4 use is growing.
I must admit I lack of skill reading statistics, however, I don't understand why you talk about PHP 5.1 while your problem is that some contracted services of your customers is changing to PHP 5.3 from 5.2.
If you need a helping hand in porting legacy 5.2 code to 5.3, feel free to contact me.
-- hakre
http://w3techs.com/**technologies/history_details/**pl-php/5http://w3techs.com/technologies/history_details/pl-php/5use of PHP5.1 is slowing faster than 5.4 use is growing.
This is wrong.
At May 2012:
PHP 5.1 starts with 4.9%
PHP 5.4 start with 0.1 %
In Februar 2013:
PHP 5.1 has now 3.2% = lose of 1.7%
PHP 5.4 has now 2.2% = grow of 2.1%
Martin Keckeis wrote:
http://w3techs.com/__technologies/history_details/__pl-php/5 <http://w3techs.com/technologies/history_details/pl-php/5> use of PHP5.1 is slowing faster than 5.4 use is growing.This is wrong.
At May 2012:
PHP 5.1 starts with 4.9%
PHP 5.4 start with 0.1 %
In Februar 2013:
PHP 5.1 has now 3.2% = lose of 1.7%
PHP 5.4 has now 2.2% = grow of 2.1%
But PHP5.4 was released 1st March ;)
So 5.6% rather than 4.9% and a loss of 2.4%
I was just looking at the graph ;)
Take up of 5.4 is having very little impact on the switch TO PHP5.3 is the point
though.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Sent from my iPhone
http://w3techs.com/**technologies/history_details/**pl-php/5http://w3techs.com/technologies/history_details/pl-php/5use of PHP5.1 is slowing faster than 5.4 use is growing.
This is wrong.
At May 2012:
PHP 5.1 starts with 4.9%
PHP 5.4 start with 0.1 %In Februar 2013:
PHP 5.1 has now 3.2% = lose of 1.7%
PHP 5.4 has now 2.2% = grow of 2.1%
One does not simply apply growth calculations by mere subtractions.
PHP 5.1 shrank by 34%
PHP 5.4 grew by 2100%
:)
hakre wrote:
In reality we have to make choices where we DO spend time. There is still
a mileof code out there being used live which is running perfectly on the
PHP5.2
infrastructure. That needs testing and reworking on PHP5.3 and then
PHP5.4
before we get around to 5.5.Why do you change the infrastructure if the code does not need it? I mean,
provide the infrastructure the code needs and done. There is more than one
vendor that offers support for PHP 5.2 infrastructure in the market. What's
the deal?The point here is supporting customers that I've 'acquired' who are
currently hosted on services that control that infrastructure. The long term
aim is to move them to servers under our control, but in the meantime until
contracts run out we have to live with such activity as 'We will be updating
to PHP5.3 on the 1st April'. The problem now is how to deal with that
situation, and paying up outstanding contracts may be the solution. The code
needs updating, and updating to 5.4 would be useful, but short term
everything needs testing and fixing for PHP5.3 :(The whole reason that ISP's are currently moving from PHP5.2 to PHP5.3
rather than PHP5.4 is that there is a better chance that their client sites
will continue to work.
http://w3techs.com/technologies/history_details/pl-php/5 use of PHP5.1 is
slowing faster than 5.4 use is growing.
If you do commercial support for customers and do not control the
environment and/or use shared hosting, then something is totally wrong
in your business model. It is also really off topic, in this mailing
list or in this discussion.
Cheers,
Pierre
@pierrejoye
Pierre Joye wrote:
If you do commercial support for customers and do not control the
environment and/or use shared hosting, then something is totally wrong
in your business model. It is also really off topic, in this mailing
list or in this discussion.
It is totally on topic!
The REASON I have gained this particular additional customer base is because
they are all having problems with keeping their sites active! I had hoped to be
producing a better set of documentation to help these type of users to cope with
the 'BC compatibility' problems they are currently fighting, but there is
nothing consistent to document. There are as many problems as customers with
several years of legacy code written by different programmers :( THEY are not
programmers ...
I hope that as some point there will be some REAL support for stopping
'developing' PHP5 and move all of the new 'features' being discussed into a nice
cleanly isolated PHP6 development stream. Then we can start documenting what IS
being removed and stop trying to track which legacy feature needs to be
re-worked rather than simply burying heads in sand and hiding them!!!
My current roadmap is based on PHP5.4 servers with nothing hidden and eventually
all of the code will be moved forward to that base, but I simply can't justify
charging some customers for all the time this takes because they HAVE working
sites currently and this is not giving them any return.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Pierre Joye wrote:
If you do commercial support for customers and do not control the
environment and/or use shared hosting, then something is totally wrong
in your business model. It is also really off topic, in this mailing
list or in this discussion.It is totally on topic!
The REASON I have gained this particular additional customer base is because
they are all having problems with keeping their sites active! I had hoped to
be producing a better set of documentation to help these type of users to
cope with the 'BC compatibility' problems they are currently fighting, but
there is nothing consistent to document. There are as many problems as
customers with several years of legacy code written by different programmers
:( THEY are not programmers ...I hope that as some point there will be some REAL support for stopping
'developing' PHP5 and move all of the new 'features' being discussed into a
nice cleanly isolated PHP6 development stream. Then we can start documenting
what IS being removed and stop trying to track which legacy feature needs to
be re-worked rather than simply burying heads in sand and hiding them!!!My current roadmap is based on PHP5.4 servers with nothing hidden and
eventually all of the code will be moved forward to that base, but I simply
can't justify charging some customers for all the time this takes because
they HAVE working sites currently and this is not giving them any return.--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk--
I hope that as some point there will be some REAL support for stopping
'developing' PHP5 and move all of the new 'features' being discussed into a
nice cleanly isolated PHP6 development stream.
Just see it as a car: you can drive it 10 years or longer, but from
time to time you need new tires or repair some stuff.
Regards,
Thomas
hi,
It is totally on topic!
no, really not.
:( THEY are not programmers ...
But you are. Evolution of the platform as a whole is part of the
support, if desired and necessary.
My current roadmap is based on PHP5.4 servers with nothing hidden and
eventually all of the code will be moved forward to that base, but I simply
can't justify charging some customers for all the time this takes because
they HAVE working sites currently and this is not giving them any return.
And the working sites will still work later as well if they don't
change the platform. However porting applications to supported
platforms is part of a support contract, and costs should or can be
described. It is even easier now that we have a fixed life cycle
(three years).
But again, how one should do support or define the needs of his
customers so they won't be in trouble (and himself neither) is not a
topic for this list.
cheers,
Pierre
@pierrejoye
Yup, so please test it against 5.5 now. Have you done so? It is rather
trivial to do. Grab it from git or there is a tarball at http://qa.php.net
Let me describe my world. I am working on an open source package. So
does another 1000 or so developers. And another 10 000 adds modules
(or maybe you'd call them plugins). I do not even know how many then
adds custom, site specific code. This whole pile of software forms an
Care to explain how am I supposed to test all that against 5.5?
Obviously you'd need every project owner doing this but they won't
because their hosts are not even on 5.4 so why would they even think
of 5.5? (5.4? A lot of people are on 5.2.)
Yes, I would say it is unattainable. You are essentially asking that we
don't make any changes.
Where did I say that?
Nothing that could possibly affect existing code
down to and including any potential warning messages even if that code
is obviously incorrect, insecure and/or not doing what the developer
intended. That means no new keywords, no new notices, no bug fixes. What
exactly can we do in a new version then?
new keywords is an interesting discussion to have -- it's actually the
first real thing to discuss as far as I can see. For example that is
something that version strings would tremendously help. You do not
need to maintain the whole lot of behaviors for every version just the
parser? Also, new keywords typically introduce new syntax. Here's an
example, a quick github code search found
https://github.com/chriso/klein.php/blob/master/klein.php#L600 this.
function yield() is not a valid usage of the new yield keyword nor is
yield() so perhaps it's not impossible to accomodate this kind of
code? Let's discuss.
New error messages could be INI controlled to avoid surprises.
Why no bugfixes? Absolutely yes to bugfixes -- once again if a piece
was not running before then that running in a new version is breaking
forward not backwards compatbility. If a bugfix changes behavior,
then again, that needs discussion, do you have any good examples? I am
not familiar enough with the bugs to say "here's a bugfix which made
foo(NULL) return NULL instead of FALSE" or somesuch.
Best,
Karoly Negyesi
Care to explain how am I supposed to test all that against 5.5?
Easy, download, install, test locally.
Obviously you'd need every project owner doing this but they won't
because their hosts are not even on 5.4 so why would they even think
of 5.5? (5.4? A lot of people are on 5.2.)
Obviously not, testing your apps against our tests versions is about
contributing to the PHP project and helping the community as a whole.
More on http://qa.php.net. It takes less time than the time you spent
here arguing about all things we do wrong.
Yup, so please test it against 5.5 now. Have you done so? It is rather
trivial to do. Grab it from git or there is a tarball at http://qa.php.netLet me describe my world. I am working on an open source package. So
does another 1000 or so developers. And another 10 000 adds modules
(or maybe you'd call them plugins). I do not even know how many then
adds custom, site specific code. This whole pile of software forms anCare to explain how am I supposed to test all that against 5.5?
Obviously you'd need every project owner doing this but they won't
because their hosts are not even on 5.4 so why would they even think
of 5.5? (5.4? A lot of people are on 5.2.)Yes, I would say it is unattainable. You are essentially asking that we
don't make any changes.Where did I say that?
Nothing that could possibly affect existing code
down to and including any potential warning messages even if that code
is obviously incorrect, insecure and/or not doing what the developer
intended. That means no new keywords, no new notices, no bug fixes. What
exactly can we do in a new version then?new keywords is an interesting discussion to have -- it's actually the
first real thing to discuss as far as I can see. For example that is
something that version strings would tremendously help. You do not
need to maintain the whole lot of behaviors for every version just the
parser? Also, new keywords typically introduce new syntax. Here's an
example, a quick github code search found
https://github.com/chriso/klein.php/blob/master/klein.php#L600 this.
function yield() is not a valid usage of the new yield keyword nor is
yield() so perhaps it's not impossible to accomodate this kind of
code? Let's discuss.
Let's not. We are not going to add version tags. There is nothing to
discuss here.
New error messages could be INI controlled to avoid surprises.
And no, more ini switches to control the nature of notices won't happen
either, sorry.
Why no bugfixes? Absolutely yes to bugfixes -- once again if a piece
was not running before then that running in a new version is breaking
forward not backwards compatbility. If a bugfix changes behavior,
then again, that needs discussion, do you have any good examples? I am
not familiar enough with the bugs to say "here's a bugfix which made
foo(NULL) returnNULLinstead of FALSE" or somesuch.
Very few bug fixes are simple in the sense that they make something work
that didn't work at all before. Usually they fix behaviour, generally in
edge-case scenarios, but not always. Two examples from PHP 5.4:
We discovered that the output of our Tiger hash was wrong. This has been
corrected in 5.4. If you have stored pre-5.4 Tiger hashes you are going
to need to fix these. See the comments of http://php.net/61307 for the
code to generate the old hashes for upgrade purposes.
The output from pack() was non-standard as well. We have brought that in
line with pack() from Perl and other languages. This can potentially
break code as we saw with it breaking Pear's Tar implementation.
Does this mean we shouldn't fix stuff like this? I don't think it does.
The way to handle it from user apps is to test your app against new
versions as early as possible and to make it clear that Drupal version
7.X is fully compatible with PHP version 5.4. It may work with later
versions, of course, but as a project you should test and state which
versions it is guaranteed to work with. Once you have done sufficient
testing with 5.5 you can certify a specific version of Drupal as being
compatible with 5.5. I don't think it needs to be any more complicated
than that.
-Rasmus
new keywords is an interesting discussion to have -- it's actually the
first real thing to discuss as far as I can see. For example that is
something that version strings would tremendously help. You do not
need to maintain the whole lot of behaviors for every version just the
parser? Also, new keywords typically introduce new syntax. Here's an
example, a quick github code search found
https://github.com/chriso/klein.php/blob/master/klein.php#L600 this.
function yield() is not a valid usage of the new yield keyword nor is
yield() so perhaps it's not impossible to accomodate this kind of
code? Let's discuss.
That's one of the easiest incompatibilities to detect (run new-php -l to
all
your files), and also to fix (replace all instances of that new keyword
with
a new name).
hi Karoly,
OK, let's try this again.
Maybe language versioning is out. That's sad, but this thread brought
to light a much more important problem I would like to try to address.I have long felt the PHP team is living in another world I do.
Sometimes yes, sometimes no.
Users form a pyramid. The bottom is shared hosts. Shared hosts that we
need to take into consideration. So if the shared world just barely
switched to 5.3 default then, alas, we can't release a version that
requires PHP 5.4 because there is no shared support for it. Also, it
worths mentioning that one of the more popular server OSes, Ubuntu LTS
also doesn't have a PHP 5.4 yet. Without software demanding 5.4, hosts
won't upgrade. This is a vicious circle that is superb hard to break.
And we changed what we used to be or used to do to ease this process.
I was told in this thread that the new release process solves this and
"it is our and our users role to explain that to their ISPs, admins,
etc".Well, what am I to explain? As I mentioned previously, if a shared
host does a PHP upgrade and their users see new error messages,
then
the host have a support problem.
Explaining new notices or warnings being non fatal or not adding BC
issues are what apps/libraries developers should document, for
previous versions. Fixing them in newer updates (even minor) is easy
and will still work when executed on older PHP versions.
It would make everyone's life so much easier if all the Drupal 8 code
that is being written and tested with 5.4 would just work 5.5 without
any problem.
That's why we do test almost all commits with all major apps or
frameworks. And that's why you should do it as well with your apps and
report any actual BC breaks.
I would absolutely love not to have this conversation again three
years from now when we need to decide to ship Drupal 9 with PHP 5.5 or
5.4 -- because we could indeed do a campaign when 5.4 is due to change
to 5.5 outright because it won't break BC with 5.4. Is this absolutely
unattainable?
What seems to be unattainable to me is this kind of discussions, you
kept on your positions and refused to understand the actual need of
adding notices or warnings for non supported/edge cases where the code
behavior cannot be guaranteed. This is a circular discussion and I
don't see how it could end.
Cheers,
Pierre
@pierrejoye
This is a circular discussion and I don't see how it could end.
I do. Let's put up an RFC for it. That is one of the reasons we
established that process, isn't it? So that ideas like this don't just end
up in infinite discussions that go nowhere?
Karoly, are you familiar with our RFC process? If not, take a look at
http://wiki.php.net/rfc. You've clearly invested a lot of thought into
this, so let's go ahead and put that into an actual proposal. I'll be glad
to help, including posting it to the wiki if you don't have an account.
I'll be honest: I don't think it'll pass. I'd be voting no on it if that
vote were held right now. But at least you'll have an actual proposal on
record and you'll have at least a week (or is it two?) to try to change
people's minds before it goes to a vote.
I think that would be the best way to close the lid on this. If somebody
brings it up again in the near future, we can simply point them to the RFC
to demonstrate that the issue has already been raised and decided. Problem
solved. If anybody has a better idea on how to put this discussion to
rest, I'm all ears. =)
--Kris
Well, either I misunderstood the policy or it's broken. Here are some
(note: please do not argue whether these are more correct than before,
they very well might be but they broke backwards compatibility):For example, in 5.4 array_diff_assoc began to throw a notice when
casting to string.Again in 5.4, using a string offset against a string throws a warning.
It wasn't doing that before.If you want I can dig around in our issue queue for more backwards
compatibility breaks but there are some.Regards,
Karoly Negyesi
As Rasmus mentioned before our current release policy allows warnings/etc.
to be added in a minor release.
If this is the same test that you mentioned before on irc, then one could
argue that this change was useful as it helped you spot and error in you
testsuite (comparing a multi-dimensional array using array_diff_assoc which
not comparing the arrays but the string "Array".
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
So, if we are talking about PHP 6, then the opening <?php tag should be
accompanied by the version it was written for, it was tested with and then
the engine could switch to a compatibility mode for that version.Seems to me that this would solve the problem where a host can't upgrade to
a more modern version for fear of breaking old code. Consequently, open
source packages -- like Drupal I am deeply involved with -- can't use more
modern PHP versions decreasing the "push" for hosts to upgrade. This is a
devilish circle and it'd be great to break it.
Agreed with the others that this should not go into the engine (and this should also not really clutter up the Internals list), but if you have a real need for running different versions of PHP for different URLs, you could pretty easily set up multiple FPM backends (one for each version you support) and have Nginx map URLs to these. It would be a maintenance headache, but not the disaster this would be if it had to be maintained in PHP-proper.
S
Hi,
So, if we are talking about PHP 6, then the opening <?php tag should be
accompanied by the version it was written for, it was tested with and then
the engine could switch to a compatibility mode for that version.Seems to me that this would solve the problem where a host can't upgrade to
a more modern version for fear of breaking old code. Consequently, open
source packages -- like Drupal I am deeply involved with -- can't use more
modern PHP versions decreasing the "push" for hosts to upgrade. This is a
devilish circle and it'd be great to break it.Regards,
Karoly Negyesi
At least two points why this makes no sense whatsoever:
-
One would have to maintain or at least keep around all previous versions
of the engine and the libraries. That would be a shitload of cruft and a
lot of maintenance work. -
Different behavior per-file is not feasible as components in both files
interact. If you have one <?php6 file and one <?php5 file and both interact
(like, you know, calling a function from one file in the other one) you
will have a pretty hard time decided what behavior this should result in.
The <?php6 behavior or the <?php5 one? So something like this can only be
done on a per-request basis (rather than per-file). And to do this on a
per-request basis you already have all the means. Just run two different
PHP versions. No issue with that; doesn't require no further support from
PHP.
Nikita
Hm, there is a slight miscommunication which is my fault.
I do not suggest a PHP engine being compatible with 5 and 6, gosh, no.
I suggest a PHP engine compatible with 5.3 and 5.4. Is that a
maintenance mess too? The difference should be a lot, lot smaller.
And yes, interaction is a problem and again I'd be glad to discuss on
how to behave for those.
Regards
NK
Hi,
So, if we are talking about PHP 6, then the opening <?php tag should be
accompanied by the version it was written for, it was tested with and then
the engine could switch to a compatibility mode for that version.Seems to me that this would solve the problem where a host can't upgrade
to
a more modern version for fear of breaking old code. Consequently, open
source packages -- like Drupal I am deeply involved with -- can't use more
modern PHP versions decreasing the "push" for hosts to upgrade. This is a
devilish circle and it'd be great to break it.Regards,
Karoly Negyesi
At least two points why this makes no sense whatsoever:
One would have to maintain or at least keep around all previous versions
of the engine and the libraries. That would be a shitload of cruft and a lot
of maintenance work.Different behavior per-file is not feasible as components in both files
interact. If you have one <?php6 file and one <?php5 file and both interact
(like, you know, calling a function from one file in the other one) you will
have a pretty hard time decided what behavior this should result in. The
<?php6 behavior or the <?php5 one? So something like this can only be done
on a per-request basis (rather than per-file). And to do this on a
per-request basis you already have all the means. Just run two different PHP
versions. No issue with that; doesn't require no further support from PHP.Nikita
Hm, there is a slight miscommunication which is my fault.
I do not suggest a PHP engine being compatible with 5 and 6, gosh, no.
I suggest a PHP engine compatible with 5.3 and 5.4. Is that a
maintenance mess too? The difference should be a lot, lot smaller.And yes, interaction is a problem and again I'd be glad to discuss on
how to behave for those.
It doesn't matter which versions you are talking about. Any sort of
multiple-personality support would turn into a complete maintenance
nightmare. We try to move things along at a responsible pace in the
direction that we want things to go. Sometimes that involves some pain.
And yes, sometimes we don't always realize that there is code out there
relying certain things. Like the fact that Drupal relied on
array_diff_asccoc() comparing array(1,2,3) to "Array" and saying those
were equivalent without any sort of notice.
-Rasmus
array_diff_asccoc() comparing array(1,2,3) to "Array" and saying those
were equivalent without any sort of notice.
That's not what happened, some contib was comparing array(1,2,3) to
array(1,2,array(3)) and even looking at the documentation it is not
clear whether the cast should or should not throw a notice. But, if
that's desired behavior, I will add a note to warn people.
Best
Karoly Negyesi
array_diff_asccoc() comparing array(1,2,3) to "Array" and saying those
were equivalent without any sort of notice.That's not what happened, some contib was comparing array(1,2,3) to
array(1,2,array(3)) and even looking at the documentation it is not
clear whether the cast should or should not throw a notice. But, if
that's desired behavior, I will add a note to warn people.
The cast should always throw a notice. The function is documented to
only compare single-dimensional arrays, so if you pass it a
multi-dimensional array it is going to treat them as a single
dimensional and the only way to do that is to cast them to scalars.
-Rasmus
Hi,
So, if we are talking about PHP 6, then the opening <?php tag should be
accompanied by the version it was written for, it was tested with and then
the engine could switch to a compatibility mode for that version.Seems to me that this would solve the problem where a host can't upgrade to
a more modern version for fear of breaking old code. Consequently, open
source packages -- like Drupal I am deeply involved with -- can't use more
modern PHP versions decreasing the "push" for hosts to upgrade. This is a
devilish circle and it'd be great to break it.Regards,
Karoly Negyesi
At least two points why this makes no sense whatsoever:
One would have to maintain or at least keep around all previous versions
of the engine and the libraries. That would be a shitload of cruft and a
lot of maintenance work.Different behavior per-file is not feasible as components in both files
interact. If you have one <?php6 file and one <?php5 file and both interact
(like, you know, calling a function from one file in the other one) you
will have a pretty hard time decided what behavior this should result in.
The <?php6 behavior or the <?php5 one? So something like this can only be
done on a per-request basis (rather than per-file). And to do this on a
per-request basis you already have all the means. Just run two different
PHP versions. No issue with that; doesn't require no further support from
PHP.Nikita
Just run two different PHP versions.
Using Debian/Ubuntu, I have "python2.6", "python2.7" and "python3"
packages, but only one version of "php5-fpm".
Maybe it would be better to have "php5.3-fpm" and "php5.4-fpm", using
/etc/php5.3 and /etc/php5.4 ?
Esp. for Travis-CI it would be much better to have separate packages
than running custom workarounds.
Regards,
Thomas
Hi,
So, if we are talking about PHP 6, then the opening <?php tag should be
accompanied by the version it was written for, it was tested with and then
the engine could switch to a compatibility mode for that version.Seems to me that this would solve the problem where a host can't upgrade to
a more modern version for fear of breaking old code. Consequently, open
source packages -- like Drupal I am deeply involved with -- can't use more
modern PHP versions decreasing the "push" for hosts to upgrade. This is a
devilish circle and it'd be great to break it.Regards,
Karoly Negyesi
At least two points why this makes no sense whatsoever:
One would have to maintain or at least keep around all previous versions
of the engine and the libraries. That would be a shitload of cruft and a
lot of maintenance work.Different behavior per-file is not feasible as components in both files
interact. If you have one <?php6 file and one <?php5 file and both interact
(like, you know, calling a function from one file in the other one) you
will have a pretty hard time decided what behavior this should result in.
The <?php6 behavior or the <?php5 one? So something like this can only be
done on a per-request basis (rather than per-file). And to do this on a
per-request basis you already have all the means. Just run two different
PHP versions. No issue with that; doesn't require no further support from
PHP.Nikita
Just run two different PHP versions.
Using Debian/Ubuntu, I have "python2.6", "python2.7" and "python3"
packages, but only one version of "php5-fpm".
Maybe it would be better to have "php5.3-fpm" and "php5.4-fpm", using
/etc/php5.3 and /etc/php5.4 ?
Esp. for Travis-CI it would be much better to have separate packages
than running custom workarounds.
Nothing stops you from doing that. Compile as many versions as you want
with different --with-config-file-path settings.
-Rasmus
Using Debian/Ubuntu, I have "python2.6", "python2.7" and "python3"
packages, but only one version of "php5-fpm".
Maybe it would be better to have "php5.3-fpm" and "php5.4-fpm", using
/etc/php5.3 and /etc/php5.4 ?
Esp. for Travis-CI it would be much better to have separate packages
than running custom workarounds.
I don't think you'd find many people here disagreeing with distribution
maintainers providing packages for multiple version at the same time
(like 5.3 and 5.4) - so that suggestion should be brought to these
people. (I know, some are reading this list.)
I've never seen anyone on this list telling a distribution maintainer
not to use /etc/php5.3 or something, please enlighten me if that's not
the case.
Greetings,
Florian
Using Debian/Ubuntu, I have "python2.6", "python2.7" and "python3"
packages, but only one version of "php5-fpm".
Maybe it would be better to have "php5.3-fpm" and "php5.4-fpm", using
/etc/php5.3 and /etc/php5.4 ?
Esp. for Travis-CI it would be much better to have separate packages
than running custom workarounds.I don't think you'd find many people here disagreeing with distribution
maintainers providing packages for multiple version at the same time
(like 5.3 and 5.4) - so that suggestion should be brought to these
people. (I know, some are reading this list.)I've never seen anyone on this list telling a distribution maintainer
not to use /etc/php5.3 or something, please enlighten me if that's not
the case.Greetings,
Florian
If I see it correctly, none of Debian, Ubuntu, openSUSE, CentOS,
Fedora currently offer more than one version of PHP.
The majority of the stable/lts distributions is currently on 5.3.x.
Getting packages for different versions and the ability to run them in
parallel might also give a push in testing alphas.
Regards,
Thomas
Thomas Bley in php.internals (Mon, 4 Feb 2013 02:06:02 +0100):
If I see it correctly, none of Debian, Ubuntu, openSUSE, CentOS,
Fedora currently offer more than one version of PHP.
Directadmin does, I am using it on CentOS.
http://forum.directadmin.com/showthread.php?t=44743
Jan
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Using Debian/Ubuntu, I have "python2.6", "python2.7" and
"python3" packages, but only one version of "php5-fpm". Maybe it
would be better to have "php5.3-fpm" and "php5.4-fpm", using
/etc/php5.3 and /etc/php5.4 ? Esp. for Travis-CI it would be much
better to have separate packages than running custom
workarounds.I don't think you'd find many people here disagreeing with
distribution maintainers providing packages for multiple version at
the same time (like 5.3 and 5.4) - so that suggestion should be
brought to these people. (I know, some are reading this list.)I've never seen anyone on this list telling a distribution
maintainer not to use /etc/php5.3 or something, please enlighten me
if that's not the case.
Gentoo has allowed its users to install multiple versions of PHP for a
few years now, and also running multiple versions of php-fpm in
parallel. So far it has not been that much of a problem to maintain,
seemingly much easier than offering the same for ruby or python.
Ole Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQEcBAEBAgAGBQJRD1o8AAoJEGurSuXEqSv12rgH/j39u30ONtvZnarsuC9A6Pjp
j/xjVTUrIIeNNKAjXQPxc8XgfJ9QBOTZxaZ6ZtocUMe4sLrwukal2o/njM7kmhSc
VYpbhNYDbExX0Rq/7qMQn8fUialoOb45sv2RsCmCk6Abx4NRWPmLYMGU/FLUYwcS
TBKHevQ6VsYDu/G85W26iyA3jpk8RTRk42mwrAtIePl0gNcpmbVHrNXhjhHF5tbB
RRm5lHvpM2BO38xSh+wAqk+sqNuTTwj3elOGKhMbwICEzHIaIiaqq+Gu4jVwsAke
Zz8R4qtfMXE4hDwIezIukAgye2GpK5WRe3wG9czMyO+xrv5Y+KkP3lRwobkxbeo=
=2+mI
-----END PGP SIGNATURE