Minimum PHP Version to 5.3.5?

classic Classic list List threaded Threaded
64 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Minimum PHP Version to 5.3.5?

Mike Willbanks
Hey All,

So; we've had a few issues due to ArrayObject's specifically in the session code; basically there is no workaround to this; you might see errors stating: "Indirect modification to overloaded property".  This is because ArrayObject does not allow offsetGet to return by reference.  Fortunately; ArrayAccess allows us to do that BUT it only allows us to return it by reference in versions greater than 5.3.3.

We really only have a few options here but here they are:
1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we basically create our own version of ArrayObject (actually have this working already and it fixes the "Indirect modification to overloaded property" in Zend\Session\Container).  For more on the code bits see: https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object

2. Rewrite anything that currently uses ArrayObject that needs to modify parameters to something more feasible.  - Really not a great choice.

3. Do nothing; keep it the same and blame PHP for the ArrayObject implementation.  This means continued bug reports on anything using ArrayObject or ArrayAccess that needs to manipulate multi-dimensional properties (yes; this happens way more than you might think).

Regards,

Mike
Reply | Threaded
Open this post in threaded view
|

RE: Minimum PHP Version to 5.3.5?

demiankatz
Does anyone keep charts of which PHP versions are distributed with which versions of OSes?  My first inclination would be to bump the minimum version -- the ArrayObject insanity caused me a lot of problems early in my work with ZF2 -- but if there's data indicating that 5.3.5 is significantly less common than 5.3.3, that might be an argument to live with the status quo.

- Demian

From: Mike Willbanks [[hidden email]]
Sent: Friday, February 01, 2013 12:55 PM
To: Zend Framework Contributors
Subject: [zf-contributors] Minimum PHP Version to 5.3.5?

Hey All,

So; we've had a few issues due to ArrayObject's specifically in the session code; basically there is no workaround to this; you might see errors stating: "Indirect modification to overloaded property".  This is because ArrayObject does not allow offsetGet to return by reference.  Fortunately; ArrayAccess allows us to do that BUT it only allows us to return it by reference in versions greater than 5.3.3.

We really only have a few options here but here they are:
1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we basically create our own version of ArrayObject (actually have this working already and it fixes the "Indirect modification to overloaded property" in Zend\Session\Container).  For more on the code bits see: https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object

2. Rewrite anything that currently uses ArrayObject that needs to modify parameters to something more feasible.  - Really not a great choice.

3. Do nothing; keep it the same and blame PHP for the ArrayObject implementation.  This means continued bug reports on anything using ArrayObject or ArrayAccess that needs to manipulate multi-dimensional properties (yes; this happens way more than you might think).

Regards,

Mike
Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

Marco Pivetta
In reply to this post by Mike Willbanks
Heya!
I think this needs a survey on what most major distros use :\

If 5.3.5 is supported by most people, it may be interesting to do the bump :)

This is used for session containers IIRC, correct?



On 1 February 2013 18:55, Mike Willbanks <[hidden email]> wrote:
Hey All,

So; we've had a few issues due to ArrayObject's specifically in the session code; basically there is no workaround to this; you might see errors stating: "Indirect modification to overloaded property".  This is because ArrayObject does not allow offsetGet to return by reference.  Fortunately; ArrayAccess allows us to do that BUT it only allows us to return it by reference in versions greater than 5.3.3.

We really only have a few options here but here they are:
1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we basically create our own version of ArrayObject (actually have this working already and it fixes the "Indirect modification to overloaded property" in Zend\Session\Container).  For more on the code bits see: https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object

2. Rewrite anything that currently uses ArrayObject that needs to modify parameters to something more feasible.  - Really not a great choice.

3. Do nothing; keep it the same and blame PHP for the ArrayObject implementation.  This means continued bug reports on anything using ArrayObject or ArrayAccess that needs to manipulate multi-dimensional properties (yes; this happens way more than you might think).

Regards,

Mike

Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

weierophinney
Administrator
In reply to this post by demiankatz
Originally, we chose 5.3.3 as that was the version being used in LTS
versions of popular distros. Since that decision was made, however, I
believe both RHEL and Ubuntu have moved to a later 5.3 version, which
means it may be a moot point.

Anybody with hard data? or grids showing the versions by distro?

On Fri, Feb 1, 2013 at 12:00 PM, Demian Katz <[hidden email]> wrote:

> Does anyone keep charts of which PHP versions are distributed with which
> versions of OSes?  My first inclination would be to bump the minimum version
> -- the ArrayObject insanity caused me a lot of problems early in my work
> with ZF2 -- but if there's data indicating that 5.3.5 is significantly less
> common than 5.3.3, that might be an argument to live with the status quo.
>
> - Demian
> ________________________________
> From: Mike Willbanks [[hidden email]]
> Sent: Friday, February 01, 2013 12:55 PM
> To: Zend Framework Contributors
> Subject: [zf-contributors] Minimum PHP Version to 5.3.5?
>
> Hey All,
>
> So; we've had a few issues due to ArrayObject's specifically in the session
> code; basically there is no workaround to this; you might see errors
> stating: "Indirect modification to overloaded property".  This is because
> ArrayObject does not allow offsetGet to return by reference.  Fortunately;
> ArrayAccess allows us to do that BUT it only allows us to return it by
> reference in versions greater than 5.3.3.
>
> We really only have a few options here but here they are:
> 1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we
> basically create our own version of ArrayObject (actually have this working
> already and it fixes the "Indirect modification to overloaded property" in
> Zend\Session\Container).  For more on the code bits see:
> https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object
>
> 2. Rewrite anything that currently uses ArrayObject that needs to modify
> parameters to something more feasible.  - Really not a great choice.
>
> 3. Do nothing; keep it the same and blame PHP for the ArrayObject
> implementation.  This means continued bug reports on anything using
> ArrayObject or ArrayAccess that needs to manipulate multi-dimensional
> properties (yes; this happens way more than you might think).
>
> Regards,
>
> Mike



--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

Mike Willbanks
Looks like from distrowatch that php 5.3.3 is on RedHat, CentOS and Debian from the major distributions (looking at most of the current ones).  Fortunately there are easy ways around it and most of these would not pass their PCI compliance anyhow with a PHP version that out of date.

There are also quite a few options for these users.

For RedHat/CentOS users:
1. Use Zend Server Community Edition
2. Use a different repository: Remi (http://blog.famillecollet.com/pages/Config-en) or iUSCommunity (http://iuscommunity.org/)
3. Compile a new version or find a different package elsewhere.

For Debian users:
1. Use Zend Server Community Edition
2. Use a different repository: Dotdeb (http://www.dotdeb.org/)
3. Compile a new version or find a different package elsewhere.

I'm actually not certain how many users are stuck at those versions right now; it might be good to look at some of the hosts out there as well.

Regards,

Mike


On Fri, Feb 1, 2013 at 10:01 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
Originally, we chose 5.3.3 as that was the version being used in LTS
versions of popular distros. Since that decision was made, however, I
believe both RHEL and Ubuntu have moved to a later 5.3 version, which
means it may be a moot point.

Anybody with hard data? or grids showing the versions by distro?

On Fri, Feb 1, 2013 at 12:00 PM, Demian Katz <[hidden email]> wrote:
> Does anyone keep charts of which PHP versions are distributed with which
> versions of OSes?  My first inclination would be to bump the minimum version
> -- the ArrayObject insanity caused me a lot of problems early in my work
> with ZF2 -- but if there's data indicating that 5.3.5 is significantly less
> common than 5.3.3, that might be an argument to live with the status quo.
>
> - Demian
> ________________________________
> From: Mike Willbanks [[hidden email]]
> Sent: Friday, February 01, 2013 12:55 PM
> To: Zend Framework Contributors
> Subject: [zf-contributors] Minimum PHP Version to 5.3.5?
>
> Hey All,
>
> So; we've had a few issues due to ArrayObject's specifically in the session
> code; basically there is no workaround to this; you might see errors
> stating: "Indirect modification to overloaded property".  This is because
> ArrayObject does not allow offsetGet to return by reference.  Fortunately;
> ArrayAccess allows us to do that BUT it only allows us to return it by
> reference in versions greater than 5.3.3.
>
> We really only have a few options here but here they are:
> 1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we
> basically create our own version of ArrayObject (actually have this working
> already and it fixes the "Indirect modification to overloaded property" in
> Zend\Session\Container).  For more on the code bits see:
> https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object
>
> 2. Rewrite anything that currently uses ArrayObject that needs to modify
> parameters to something more feasible.  - Really not a great choice.
>
> 3. Do nothing; keep it the same and blame PHP for the ArrayObject
> implementation.  This means continued bug reports on anything using
> ArrayObject or ArrayAccess that needs to manipulate multi-dimensional
> properties (yes; this happens way more than you might think).
>
> Regards,
>
> Mike



--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

Sascha-Oliver Prolic
Hi,

I tried to make a list of current php versions in major linux distros.
Feel free to correct mistakes or add missing distros.

Best Regards

Sascha


2013/2/1 Mike Willbanks <[hidden email]>
Looks like from distrowatch that php 5.3.3 is on RedHat, CentOS and Debian from the major distributions (looking at most of the current ones).  Fortunately there are easy ways around it and most of these would not pass their PCI compliance anyhow with a PHP version that out of date.

There are also quite a few options for these users.

For RedHat/CentOS users:
1. Use Zend Server Community Edition
2. Use a different repository: Remi (http://blog.famillecollet.com/pages/Config-en) or iUSCommunity (http://iuscommunity.org/)
3. Compile a new version or find a different package elsewhere.

For Debian users:
1. Use Zend Server Community Edition
2. Use a different repository: Dotdeb (http://www.dotdeb.org/)
3. Compile a new version or find a different package elsewhere.

I'm actually not certain how many users are stuck at those versions right now; it might be good to look at some of the hosts out there as well.

Regards,

Mike


On Fri, Feb 1, 2013 at 10:01 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
Originally, we chose 5.3.3 as that was the version being used in LTS
versions of popular distros. Since that decision was made, however, I
believe both RHEL and Ubuntu have moved to a later 5.3 version, which
means it may be a moot point.

Anybody with hard data? or grids showing the versions by distro?

On Fri, Feb 1, 2013 at 12:00 PM, Demian Katz <[hidden email]> wrote:
> Does anyone keep charts of which PHP versions are distributed with which
> versions of OSes?  My first inclination would be to bump the minimum version
> -- the ArrayObject insanity caused me a lot of problems early in my work
> with ZF2 -- but if there's data indicating that 5.3.5 is significantly less
> common than 5.3.3, that might be an argument to live with the status quo.
>
> - Demian
> ________________________________
> From: Mike Willbanks [[hidden email]]
> Sent: Friday, February 01, 2013 12:55 PM
> To: Zend Framework Contributors
> Subject: [zf-contributors] Minimum PHP Version to 5.3.5?
>
> Hey All,
>
> So; we've had a few issues due to ArrayObject's specifically in the session
> code; basically there is no workaround to this; you might see errors
> stating: "Indirect modification to overloaded property".  This is because
> ArrayObject does not allow offsetGet to return by reference.  Fortunately;
> ArrayAccess allows us to do that BUT it only allows us to return it by
> reference in versions greater than 5.3.3.
>
> We really only have a few options here but here they are:
> 1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we
> basically create our own version of ArrayObject (actually have this working
> already and it fixes the "Indirect modification to overloaded property" in
> Zend\Session\Container).  For more on the code bits see:
> https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object
>
> 2. Rewrite anything that currently uses ArrayObject that needs to modify
> parameters to something more feasible.  - Really not a great choice.
>
> 3. Do nothing; keep it the same and blame PHP for the ArrayObject
> implementation.  This means continued bug reports on anything using
> ArrayObject or ArrayAccess that needs to manipulate multi-dimensional
> properties (yes; this happens way more than you might think).
>
> Regards,
>
> Mike



--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc




--
Sascha-Oliver Prolic
Reply | Threaded
Open this post in threaded view
|

RE: Minimum PHP Version to 5.3.5?

demiankatz
Too bad about CentOS and RHEL -- though that's not surprising, since they tend to lag behind.  Many users of those OSes will be accustomed to installing newer versions by other means... though at least a handful will be hampered by institutional policies, which is a shame.

- Demian

From: Sascha-Oliver Prolic [[hidden email]]
Sent: Friday, February 01, 2013 3:05 PM
To: Mike Willbanks
Cc: Matthew Weier O'Phinney; Demian Katz; Zend Framework Contributors
Subject: Re: [zf-contributors] Minimum PHP Version to 5.3.5?

Hi,

I tried to make a list of current php versions in major linux distros.
Feel free to correct mistakes or add missing distros.

Best Regards

Sascha


2013/2/1 Mike Willbanks <[hidden email]>
Looks like from distrowatch that php 5.3.3 is on RedHat, CentOS and Debian from the major distributions (looking at most of the current ones).  Fortunately there are easy ways around it and most of these would not pass their PCI compliance anyhow with a PHP version that out of date.

There are also quite a few options for these users.

For RedHat/CentOS users:
1. Use Zend Server Community Edition
2. Use a different repository: Remi (http://blog.famillecollet.com/pages/Config-en) or iUSCommunity (http://iuscommunity.org/)
3. Compile a new version or find a different package elsewhere.

For Debian users:
1. Use Zend Server Community Edition
2. Use a different repository: Dotdeb (http://www.dotdeb.org/)
3. Compile a new version or find a different package elsewhere.

I'm actually not certain how many users are stuck at those versions right now; it might be good to look at some of the hosts out there as well.

Regards,

Mike


On Fri, Feb 1, 2013 at 10:01 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
Originally, we chose 5.3.3 as that was the version being used in LTS
versions of popular distros. Since that decision was made, however, I
believe both RHEL and Ubuntu have moved to a later 5.3 version, which
means it may be a moot point.

Anybody with hard data? or grids showing the versions by distro?

On Fri, Feb 1, 2013 at 12:00 PM, Demian Katz <[hidden email]> wrote:
> Does anyone keep charts of which PHP versions are distributed with which
> versions of OSes?  My first inclination would be to bump the minimum version
> -- the ArrayObject insanity caused me a lot of problems early in my work
> with ZF2 -- but if there's data indicating that 5.3.5 is significantly less
> common than 5.3.3, that might be an argument to live with the status quo.
>
> - Demian
> ________________________________
> From: Mike Willbanks [[hidden email]]
> Sent: Friday, February 01, 2013 12:55 PM
> To: Zend Framework Contributors
> Subject: [zf-contributors] Minimum PHP Version to 5.3.5?
>
> Hey All,
>
> So; we've had a few issues due to ArrayObject's specifically in the session
> code; basically there is no workaround to this; you might see errors
> stating: "Indirect modification to overloaded property".  This is because
> ArrayObject does not allow offsetGet to return by reference.  Fortunately;
> ArrayAccess allows us to do that BUT it only allows us to return it by
> reference in versions greater than 5.3.3.
>
> We really only have a few options here but here they are:
> 1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we
> basically create our own version of ArrayObject (actually have this working
> already and it fixes the "Indirect modification to overloaded property" in
> Zend\Session\Container).  For more on the code bits see:
> https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object
>
> 2. Rewrite anything that currently uses ArrayObject that needs to modify
> parameters to something more feasible.  - Really not a great choice.
>
> 3. Do nothing; keep it the same and blame PHP for the ArrayObject
> implementation.  This means continued bug reports on anything using
> ArrayObject or ArrayAccess that needs to manipulate multi-dimensional
> properties (yes; this happens way more than you might think).
>
> Regards,
>
> Mike



--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc




--
Sascha-Oliver Prolic
Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

machek
In reply to this post by Mike Willbanks
Hi,
I don't think this is exactly true.

For example Debian Squeeze has php5 (5.3.3-7+squeeze14)  -7+squeeze14 means security patches, means of course it is PCI compliant.
It doesn't means fixed other bugs, which is sometimes very annoying.

But lot's of people are stacked with hosting where you have to use just standard repository, means you have to stay with php 5.3.3
I think it would be mistake to require 5.3.5, when major Linux distributions at the moment provide just 5.3.3.

Regards

Zdenek Machek

On 1 February 2013 19:16, Mike Willbanks <[hidden email]> wrote:
Looks like from distrowatch that php 5.3.3 is on RedHat, CentOS and Debian from the major distributions (looking at most of the current ones).  Fortunately there are easy ways around it and most of these would not pass their PCI compliance anyhow with a PHP version that out of date.

There are also quite a few options for these users.

For RedHat/CentOS users:
1. Use Zend Server Community Edition
2. Use a different repository: Remi (http://blog.famillecollet.com/pages/Config-en) or iUSCommunity (http://iuscommunity.org/)
3. Compile a new version or find a different package elsewhere.

For Debian users:
1. Use Zend Server Community Edition
2. Use a different repository: Dotdeb (http://www.dotdeb.org/)
3. Compile a new version or find a different package elsewhere.

I'm actually not certain how many users are stuck at those versions right now; it might be good to look at some of the hosts out there as well.

Regards,

Mike


On Fri, Feb 1, 2013 at 10:01 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
Originally, we chose 5.3.3 as that was the version being used in LTS
versions of popular distros. Since that decision was made, however, I
believe both RHEL and Ubuntu have moved to a later 5.3 version, which
means it may be a moot point.

Anybody with hard data? or grids showing the versions by distro?

On Fri, Feb 1, 2013 at 12:00 PM, Demian Katz <[hidden email]> wrote:
> Does anyone keep charts of which PHP versions are distributed with which
> versions of OSes?  My first inclination would be to bump the minimum version
> -- the ArrayObject insanity caused me a lot of problems early in my work
> with ZF2 -- but if there's data indicating that 5.3.5 is significantly less
> common than 5.3.3, that might be an argument to live with the status quo.
>
> - Demian
> ________________________________
> From: Mike Willbanks [[hidden email]]
> Sent: Friday, February 01, 2013 12:55 PM
> To: Zend Framework Contributors
> Subject: [zf-contributors] Minimum PHP Version to 5.3.5?
>
> Hey All,
>
> So; we've had a few issues due to ArrayObject's specifically in the session
> code; basically there is no workaround to this; you might see errors
> stating: "Indirect modification to overloaded property".  This is because
> ArrayObject does not allow offsetGet to return by reference.  Fortunately;
> ArrayAccess allows us to do that BUT it only allows us to return it by
> reference in versions greater than 5.3.3.
>
> We really only have a few options here but here they are:
> 1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we
> basically create our own version of ArrayObject (actually have this working
> already and it fixes the "Indirect modification to overloaded property" in
> Zend\Session\Container).  For more on the code bits see:
> https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object
>
> 2. Rewrite anything that currently uses ArrayObject that needs to modify
> parameters to something more feasible.  - Really not a great choice.
>
> 3. Do nothing; keep it the same and blame PHP for the ArrayObject
> implementation.  This means continued bug reports on anything using
> ArrayObject or ArrayAccess that needs to manipulate multi-dimensional
> properties (yes; this happens way more than you might think).
>
> Regards,
>
> Mike



--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc


Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

Gregory
It really should be about the code. Use the version that suits the development environment the best. ZF1.x already exists and within the time span, it better to target the needs of the code foremost.


On Fri, Feb 1, 2013 at 2:22 PM, Zdenek Machek <[hidden email]> wrote:
Hi,
I don't think this is exactly true.

For example Debian Squeeze has php5 (5.3.3-7+squeeze14)  -7+squeeze14 means security patches, means of course it is PCI compliant.
It doesn't means fixed other bugs, which is sometimes very annoying.

But lot's of people are stacked with hosting where you have to use just standard repository, means you have to stay with php 5.3.3
I think it would be mistake to require 5.3.5, when major Linux distributions at the moment provide just 5.3.3.

Regards

Zdenek Machek


On 1 February 2013 19:16, Mike Willbanks <[hidden email]> wrote:
Looks like from distrowatch that php 5.3.3 is on RedHat, CentOS and Debian from the major distributions (looking at most of the current ones).  Fortunately there are easy ways around it and most of these would not pass their PCI compliance anyhow with a PHP version that out of date.

There are also quite a few options for these users.

For RedHat/CentOS users:
1. Use Zend Server Community Edition
2. Use a different repository: Remi (http://blog.famillecollet.com/pages/Config-en) or iUSCommunity (http://iuscommunity.org/)
3. Compile a new version or find a different package elsewhere.

For Debian users:
1. Use Zend Server Community Edition
2. Use a different repository: Dotdeb (http://www.dotdeb.org/)
3. Compile a new version or find a different package elsewhere.

I'm actually not certain how many users are stuck at those versions right now; it might be good to look at some of the hosts out there as well.

Regards,

Mike


On Fri, Feb 1, 2013 at 10:01 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
Originally, we chose 5.3.3 as that was the version being used in LTS
versions of popular distros. Since that decision was made, however, I
believe both RHEL and Ubuntu have moved to a later 5.3 version, which
means it may be a moot point.

Anybody with hard data? or grids showing the versions by distro?

On Fri, Feb 1, 2013 at 12:00 PM, Demian Katz <[hidden email]> wrote:
> Does anyone keep charts of which PHP versions are distributed with which
> versions of OSes?  My first inclination would be to bump the minimum version
> -- the ArrayObject insanity caused me a lot of problems early in my work
> with ZF2 -- but if there's data indicating that 5.3.5 is significantly less
> common than 5.3.3, that might be an argument to live with the status quo.
>
> - Demian
> ________________________________
> From: Mike Willbanks [[hidden email]]
> Sent: Friday, February 01, 2013 12:55 PM
> To: Zend Framework Contributors
> Subject: [zf-contributors] Minimum PHP Version to 5.3.5?
>
> Hey All,
>
> So; we've had a few issues due to ArrayObject's specifically in the session
> code; basically there is no workaround to this; you might see errors
> stating: "Indirect modification to overloaded property".  This is because
> ArrayObject does not allow offsetGet to return by reference.  Fortunately;
> ArrayAccess allows us to do that BUT it only allows us to return it by
> reference in versions greater than 5.3.3.
>
> We really only have a few options here but here they are:
> 1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we
> basically create our own version of ArrayObject (actually have this working
> already and it fixes the "Indirect modification to overloaded property" in
> Zend\Session\Container).  For more on the code bits see:
> https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object
>
> 2. Rewrite anything that currently uses ArrayObject that needs to modify
> parameters to something more feasible.  - Really not a great choice.
>
> 3. Do nothing; keep it the same and blame PHP for the ArrayObject
> implementation.  This means continued bug reports on anything using
> ArrayObject or ArrayAccess that needs to manipulate multi-dimensional
> properties (yes; this happens way more than you might think).
>
> Regards,
>
> Mike



--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc





--
Greg
Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

Mike Willbanks
In reply to this post by machek
Yes I know there are security patches; it also all depends on who does your PCI compliance and if that is good enough or not.  In the case I am in; we have to be above certain patch releases (i remember we had severs to upgraded from like PHP 5.3.6 to something else.  Either way; we do face fundamental issues:

Overall; we're going to start hitting larger and larger issues as time moves forward and the issues comes down to:
1. We likely break BC because we need to fix a bug due to a bug in particular PHP versions
2. We ignore the bug and do not resolve it until we are able to up the minimum version requirements

#1 may not __always__ break BC but in the majority of cases there will be slight BC breaks due to it.  It is certainly unfortunate.

At this point; there are two things that should __never__ be used in the framework that need to do array manipulation (aka unset being the largest): ArrayObject and ArrayAccess.  ArrayAccess could be lifted after 5.3.4 BUT ArrayObject contains a fundamental problem and should __only__ be used if and only if the object is going to be for: single dimension arrays OR reading only.

Unfortunately at this point both are utilized in various places in the framework and I had to do a ton of work to make an ArrayObject manually to attempt to get around some issues but it has to leverage ArrayAccess; well our minimum version requirements are 5.3.3.  This means that we would have to live with the bugs for those users and then provide alternative classes to load in the event the user is above 5.3.4 - basically going into dynamic loading of classes which do have performance penalties. 

Regards,

Mike

On Fri, Feb 1, 2013 at 12:22 PM, Zdenek Machek <[hidden email]> wrote:
Hi,
I don't think this is exactly true.

For example Debian Squeeze has php5 (5.3.3-7+squeeze14)  -7+squeeze14 means security patches, means of course it is PCI compliant.
It doesn't means fixed other bugs, which is sometimes very annoying.

But lot's of people are stacked with hosting where you have to use just standard repository, means you have to stay with php 5.3.3
I think it would be mistake to require 5.3.5, when major Linux distributions at the moment provide just 5.3.3.

Regards

Zdenek Machek


On 1 February 2013 19:16, Mike Willbanks <[hidden email]> wrote:
Looks like from distrowatch that php 5.3.3 is on RedHat, CentOS and Debian from the major distributions (looking at most of the current ones).  Fortunately there are easy ways around it and most of these would not pass their PCI compliance anyhow with a PHP version that out of date.

There are also quite a few options for these users.

For RedHat/CentOS users:
1. Use Zend Server Community Edition
2. Use a different repository: Remi (http://blog.famillecollet.com/pages/Config-en) or iUSCommunity (http://iuscommunity.org/)
3. Compile a new version or find a different package elsewhere.

For Debian users:
1. Use Zend Server Community Edition
2. Use a different repository: Dotdeb (http://www.dotdeb.org/)
3. Compile a new version or find a different package elsewhere.

I'm actually not certain how many users are stuck at those versions right now; it might be good to look at some of the hosts out there as well.

Regards,

Mike


On Fri, Feb 1, 2013 at 10:01 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
Originally, we chose 5.3.3 as that was the version being used in LTS
versions of popular distros. Since that decision was made, however, I
believe both RHEL and Ubuntu have moved to a later 5.3 version, which
means it may be a moot point.

Anybody with hard data? or grids showing the versions by distro?

On Fri, Feb 1, 2013 at 12:00 PM, Demian Katz <[hidden email]> wrote:
> Does anyone keep charts of which PHP versions are distributed with which
> versions of OSes?  My first inclination would be to bump the minimum version
> -- the ArrayObject insanity caused me a lot of problems early in my work
> with ZF2 -- but if there's data indicating that 5.3.5 is significantly less
> common than 5.3.3, that might be an argument to live with the status quo.
>
> - Demian
> ________________________________
> From: Mike Willbanks [[hidden email]]
> Sent: Friday, February 01, 2013 12:55 PM
> To: Zend Framework Contributors
> Subject: [zf-contributors] Minimum PHP Version to 5.3.5?
>
> Hey All,
>
> So; we've had a few issues due to ArrayObject's specifically in the session
> code; basically there is no workaround to this; you might see errors
> stating: "Indirect modification to overloaded property".  This is because
> ArrayObject does not allow offsetGet to return by reference.  Fortunately;
> ArrayAccess allows us to do that BUT it only allows us to return it by
> reference in versions greater than 5.3.3.
>
> We really only have a few options here but here they are:
> 1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we
> basically create our own version of ArrayObject (actually have this working
> already and it fixes the "Indirect modification to overloaded property" in
> Zend\Session\Container).  For more on the code bits see:
> https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object
>
> 2. Rewrite anything that currently uses ArrayObject that needs to modify
> parameters to something more feasible.  - Really not a great choice.
>
> 3. Do nothing; keep it the same and blame PHP for the ArrayObject
> implementation.  This means continued bug reports on anything using
> ArrayObject or ArrayAccess that needs to manipulate multi-dimensional
> properties (yes; this happens way more than you might think).
>
> Regards,
>
> Mike



--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc



Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

zburnham
This was meant to go to the full list, sorry Mike.  Thanks, Gmail.

On Mon, Feb 4, 2013 at 9:51 AM, Zachary Burnham <[hidden email]> wrote:
My two cents:

It is not reasonable to ask someone to upgrade past what their distribution/OS offers in terms of a php package.  When people evaluate the use of a given framework, and they look at the minimum requirements, and find that CentOS or RHEL, for example, does not meet them, they will not use the framework, instead of following any instructions about how to install an alternative package.  I am fortunate in that I am able to install virtually any package that I wish on our servers, but the vast majority of developers do not have that freedom, either due to corporate procedures, a lack of systems administration experience, or inadequate resources; very often, all three. 

If the solution is to work around it in the code (which I understand is a lot of work) or prevent a large number of people from being able to use the framework, that's not even close for me.

Z



On Fri, Feb 1, 2013 at 4:27 PM, Mike Willbanks <[hidden email]> wrote:
Yes I know there are security patches; it also all depends on who does your PCI compliance and if that is good enough or not.  In the case I am in; we have to be above certain patch releases (i remember we had severs to upgraded from like PHP 5.3.6 to something else.  Either way; we do face fundamental issues:

Overall; we're going to start hitting larger and larger issues as time moves forward and the issues comes down to:
1. We likely break BC because we need to fix a bug due to a bug in particular PHP versions
2. We ignore the bug and do not resolve it until we are able to up the minimum version requirements

#1 may not __always__ break BC but in the majority of cases there will be slight BC breaks due to it.  It is certainly unfortunate.

At this point; there are two things that should __never__ be used in the framework that need to do array manipulation (aka unset being the largest): ArrayObject and ArrayAccess.  ArrayAccess could be lifted after 5.3.4 BUT ArrayObject contains a fundamental problem and should __only__ be used if and only if the object is going to be for: single dimension arrays OR reading only.

Unfortunately at this point both are utilized in various places in the framework and I had to do a ton of work to make an ArrayObject manually to attempt to get around some issues but it has to leverage ArrayAccess; well our minimum version requirements are 5.3.3.  This means that we would have to live with the bugs for those users and then provide alternative classes to load in the event the user is above 5.3.4 - basically going into dynamic loading of classes which do have performance penalties. 

Regards,

Mike

On Fri, Feb 1, 2013 at 12:22 PM, Zdenek Machek <[hidden email]> wrote:
Hi,
I don't think this is exactly true.

For example Debian Squeeze has php5 (5.3.3-7+squeeze14)  -7+squeeze14 means security patches, means of course it is PCI compliant.
It doesn't means fixed other bugs, which is sometimes very annoying.

But lot's of people are stacked with hosting where you have to use just standard repository, means you have to stay with php 5.3.3
I think it would be mistake to require 5.3.5, when major Linux distributions at the moment provide just 5.3.3.

Regards

Zdenek Machek


On 1 February 2013 19:16, Mike Willbanks <[hidden email]> wrote:
Looks like from distrowatch that php 5.3.3 is on RedHat, CentOS and Debian from the major distributions (looking at most of the current ones).  Fortunately there are easy ways around it and most of these would not pass their PCI compliance anyhow with a PHP version that out of date.

There are also quite a few options for these users.

For RedHat/CentOS users:
1. Use Zend Server Community Edition
2. Use a different repository: Remi (http://blog.famillecollet.com/pages/Config-en) or iUSCommunity (http://iuscommunity.org/)
3. Compile a new version or find a different package elsewhere.

For Debian users:
1. Use Zend Server Community Edition
2. Use a different repository: Dotdeb (http://www.dotdeb.org/)
3. Compile a new version or find a different package elsewhere.

I'm actually not certain how many users are stuck at those versions right now; it might be good to look at some of the hosts out there as well.

Regards,

Mike


On Fri, Feb 1, 2013 at 10:01 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
Originally, we chose 5.3.3 as that was the version being used in LTS
versions of popular distros. Since that decision was made, however, I
believe both RHEL and Ubuntu have moved to a later 5.3 version, which
means it may be a moot point.

Anybody with hard data? or grids showing the versions by distro?

On Fri, Feb 1, 2013 at 12:00 PM, Demian Katz <[hidden email]> wrote:
> Does anyone keep charts of which PHP versions are distributed with which
> versions of OSes?  My first inclination would be to bump the minimum version
> -- the ArrayObject insanity caused me a lot of problems early in my work
> with ZF2 -- but if there's data indicating that 5.3.5 is significantly less
> common than 5.3.3, that might be an argument to live with the status quo.
>
> - Demian
> ________________________________
> From: Mike Willbanks [[hidden email]]
> Sent: Friday, February 01, 2013 12:55 PM
> To: Zend Framework Contributors
> Subject: [zf-contributors] Minimum PHP Version to 5.3.5?
>
> Hey All,
>
> So; we've had a few issues due to ArrayObject's specifically in the session
> code; basically there is no workaround to this; you might see errors
> stating: "Indirect modification to overloaded property".  This is because
> ArrayObject does not allow offsetGet to return by reference.  Fortunately;
> ArrayAccess allows us to do that BUT it only allows us to return it by
> reference in versions greater than 5.3.3.
>
> We really only have a few options here but here they are:
> 1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we
> basically create our own version of ArrayObject (actually have this working
> already and it fixes the "Indirect modification to overloaded property" in
> Zend\Session\Container).  For more on the code bits see:
> https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object
>
> 2. Rewrite anything that currently uses ArrayObject that needs to modify
> parameters to something more feasible.  - Really not a great choice.
>
> 3. Do nothing; keep it the same and blame PHP for the ArrayObject
> implementation.  This means continued bug reports on anything using
> ArrayObject or ArrayAccess that needs to manipulate multi-dimensional
> properties (yes; this happens way more than you might think).
>
> Regards,
>
> Mike



--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc





Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

Mike Willbanks

Hi,

On Mon, Feb 4, 2013 at 9:51 AM, Zachary Burnham <[hidden email]> wrote:
My two cents:

It is not reasonable to ask someone to upgrade past what their distribution/OS offers in terms of a php package.  When people evaluate the use of a given framework, and they look at the minimum requirements, and find that CentOS or RHEL, for example, does not meet them, they will not use the framework, instead of following any instructions about how to install an alternative package.  I am fortunate in that I am able to install virtually any package that I wish on our servers, but the vast majority of developers do not have that freedom, either due to corporate procedures, a lack of systems administration experience, or inadequate resources; very often, all three. 

If the solution is to work around it in the code (which I understand is a lot of work) or prevent a large number of people from being able to use the framework, that's not even close for me.

So the issue is; we can't really workaround this particular item in the code because the workaround would require 5.3.4.  Therefore the issues of unsetting a multi-dimensional array in several areas of the code will be fundamentally broken.  Unfortunately there is really no good solid workaround nor fix for the issue and unfortunately it would also then be an issue for people that have upgraded their PHP installations.

This now would get us into a position where we have to dynamically create alternative versions of a class to fix a bug due to the minimum version requirement.  I guess for me in most organizations I have simply been able to ask them to upgrade and provide the areas for a replacement repository including providing setup instructions.  Anyhow; the hard part here is just to note that the framework will contain fundamental issues until the minimum version moves a bit higher.  Right now it will be with ArrayAccess and ArrayObject; I am certain there are additional issues as well.

 


Z



On Fri, Feb 1, 2013 at 4:27 PM, Mike Willbanks <[hidden email]> wrote:
Yes I know there are security patches; it also all depends on who does your PCI compliance and if that is good enough or not.  In the case I am in; we have to be above certain patch releases (i remember we had severs to upgraded from like PHP 5.3.6 to something else.  Either way; we do face fundamental issues:

Overall; we're going to start hitting larger and larger issues as time moves forward and the issues comes down to:
1. We likely break BC because we need to fix a bug due to a bug in particular PHP versions
2. We ignore the bug and do not resolve it until we are able to up the minimum version requirements

#1 may not __always__ break BC but in the majority of cases there will be slight BC breaks due to it.  It is certainly unfortunate.

At this point; there are two things that should __never__ be used in the framework that need to do array manipulation (aka unset being the largest): ArrayObject and ArrayAccess.  ArrayAccess could be lifted after 5.3.4 BUT ArrayObject contains a fundamental problem and should __only__ be used if and only if the object is going to be for: single dimension arrays OR reading only.

Unfortunately at this point both are utilized in various places in the framework and I had to do a ton of work to make an ArrayObject manually to attempt to get around some issues but it has to leverage ArrayAccess; well our minimum version requirements are 5.3.3.  This means that we would have to live with the bugs for those users and then provide alternative classes to load in the event the user is above 5.3.4 - basically going into dynamic loading of classes which do have performance penalties. 

Regards,

Mike

On Fri, Feb 1, 2013 at 12:22 PM, Zdenek Machek <[hidden email]> wrote:
Hi,
I don't think this is exactly true.

For example Debian Squeeze has php5 (5.3.3-7+squeeze14)  -7+squeeze14 means security patches, means of course it is PCI compliant.
It doesn't means fixed other bugs, which is sometimes very annoying.

But lot's of people are stacked with hosting where you have to use just standard repository, means you have to stay with php 5.3.3
I think it would be mistake to require 5.3.5, when major Linux distributions at the moment provide just 5.3.3.

Regards

Zdenek Machek


On 1 February 2013 19:16, Mike Willbanks <[hidden email]> wrote:
Looks like from distrowatch that php 5.3.3 is on RedHat, CentOS and Debian from the major distributions (looking at most of the current ones).  Fortunately there are easy ways around it and most of these would not pass their PCI compliance anyhow with a PHP version that out of date.

There are also quite a few options for these users.

For RedHat/CentOS users:
1. Use Zend Server Community Edition
2. Use a different repository: Remi (http://blog.famillecollet.com/pages/Config-en) or iUSCommunity (http://iuscommunity.org/)
3. Compile a new version or find a different package elsewhere.

For Debian users:
1. Use Zend Server Community Edition
2. Use a different repository: Dotdeb (http://www.dotdeb.org/)
3. Compile a new version or find a different package elsewhere.

I'm actually not certain how many users are stuck at those versions right now; it might be good to look at some of the hosts out there as well.

Regards,

Mike


On Fri, Feb 1, 2013 at 10:01 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
Originally, we chose 5.3.3 as that was the version being used in LTS
versions of popular distros. Since that decision was made, however, I
believe both RHEL and Ubuntu have moved to a later 5.3 version, which
means it may be a moot point.

Anybody with hard data? or grids showing the versions by distro?

On Fri, Feb 1, 2013 at 12:00 PM, Demian Katz <[hidden email]> wrote:
> Does anyone keep charts of which PHP versions are distributed with which
> versions of OSes?  My first inclination would be to bump the minimum version
> -- the ArrayObject insanity caused me a lot of problems early in my work
> with ZF2 -- but if there's data indicating that 5.3.5 is significantly less
> common than 5.3.3, that might be an argument to live with the status quo.
>
> - Demian
> ________________________________
> From: Mike Willbanks [[hidden email]]
> Sent: Friday, February 01, 2013 12:55 PM
> To: Zend Framework Contributors
> Subject: [zf-contributors] Minimum PHP Version to 5.3.5?
>
> Hey All,
>
> So; we've had a few issues due to ArrayObject's specifically in the session
> code; basically there is no workaround to this; you might see errors
> stating: "Indirect modification to overloaded property".  This is because
> ArrayObject does not allow offsetGet to return by reference.  Fortunately;
> ArrayAccess allows us to do that BUT it only allows us to return it by
> reference in versions greater than 5.3.3.
>
> We really only have a few options here but here they are:
> 1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we
> basically create our own version of ArrayObject (actually have this working
> already and it fixes the "Indirect modification to overloaded property" in
> Zend\Session\Container).  For more on the code bits see:
> https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object
>
> 2. Rewrite anything that currently uses ArrayObject that needs to modify
> parameters to something more feasible.  - Really not a great choice.
>
> 3. Do nothing; keep it the same and blame PHP for the ArrayObject
> implementation.  This means continued bug reports on anything using
> ArrayObject or ArrayAccess that needs to manipulate multi-dimensional
> properties (yes; this happens way more than you might think).
>
> Regards,
>
> Mike



--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc






Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

Anthony Shireman
In reply to this post by zburnham
It seems that any direction (increasing the version required or rewriting the framework) will involve a bit of work and I guess the question is who will do the work and where will the biggest benefit be? As Matthew said, ZF2 was targeted at 5.3.3 and since then PHP has been upgraded to 5.3.21. The 5.3 series is entering it's end of life in March. I'd like to say that upping the version requirement shouldn't be a bad idea even over the course of the life of ZF2. The minor version increases provide improved performance, stability and security so choosing to not utilize them seems like a poor choice. Changing the framework to fix an issue that's already been fixed seems like a waste of the framework developers time. Bumping the minimum version to just above what's required to fix the issue seems like the best thing to do and requires minimal effort on the framework developers and helps out the majority of the users. (Side note: Has a recent "What version of PHP are you using poll happened?" Should it?) It doesn't seem like a huge jump for those that are still using 5.3.3 to go to 5.3.5 considering that the distros that are still at that version seem to be in the minority. Anyone who is in an environment that just *cannot* go from 5.3.3->5.3.5 with fairly minimal effort?


On Mon, Feb 4, 2013 at 6:53 AM, Zachary Burnham <[hidden email]> wrote:
This was meant to go to the full list, sorry Mike.  Thanks, Gmail.

On Mon, Feb 4, 2013 at 9:51 AM, Zachary Burnham <[hidden email]> wrote:
My two cents:

It is not reasonable to ask someone to upgrade past what their distribution/OS offers in terms of a php package.  When people evaluate the use of a given framework, and they look at the minimum requirements, and find that CentOS or RHEL, for example, does not meet them, they will not use the framework, instead of following any instructions about how to install an alternative package.  I am fortunate in that I am able to install virtually any package that I wish on our servers, but the vast majority of developers do not have that freedom, either due to corporate procedures, a lack of systems administration experience, or inadequate resources; very often, all three. 

If the solution is to work around it in the code (which I understand is a lot of work) or prevent a large number of people from being able to use the framework, that's not even close for me.

Z



On Fri, Feb 1, 2013 at 4:27 PM, Mike Willbanks <[hidden email]> wrote:
Yes I know there are security patches; it also all depends on who does your PCI compliance and if that is good enough or not.  In the case I am in; we have to be above certain patch releases (i remember we had severs to upgraded from like PHP 5.3.6 to something else.  Either way; we do face fundamental issues:

Overall; we're going to start hitting larger and larger issues as time moves forward and the issues comes down to:
1. We likely break BC because we need to fix a bug due to a bug in particular PHP versions
2. We ignore the bug and do not resolve it until we are able to up the minimum version requirements

#1 may not __always__ break BC but in the majority of cases there will be slight BC breaks due to it.  It is certainly unfortunate.

At this point; there are two things that should __never__ be used in the framework that need to do array manipulation (aka unset being the largest): ArrayObject and ArrayAccess.  ArrayAccess could be lifted after 5.3.4 BUT ArrayObject contains a fundamental problem and should __only__ be used if and only if the object is going to be for: single dimension arrays OR reading only.

Unfortunately at this point both are utilized in various places in the framework and I had to do a ton of work to make an ArrayObject manually to attempt to get around some issues but it has to leverage ArrayAccess; well our minimum version requirements are 5.3.3.  This means that we would have to live with the bugs for those users and then provide alternative classes to load in the event the user is above 5.3.4 - basically going into dynamic loading of classes which do have performance penalties. 

Regards,

Mike

On Fri, Feb 1, 2013 at 12:22 PM, Zdenek Machek <[hidden email]> wrote:
Hi,
I don't think this is exactly true.

For example Debian Squeeze has php5 (5.3.3-7+squeeze14)  -7+squeeze14 means security patches, means of course it is PCI compliant.
It doesn't means fixed other bugs, which is sometimes very annoying.

But lot's of people are stacked with hosting where you have to use just standard repository, means you have to stay with php 5.3.3
I think it would be mistake to require 5.3.5, when major Linux distributions at the moment provide just 5.3.3.

Regards

Zdenek Machek


On 1 February 2013 19:16, Mike Willbanks <[hidden email]> wrote:
Looks like from distrowatch that php 5.3.3 is on RedHat, CentOS and Debian from the major distributions (looking at most of the current ones).  Fortunately there are easy ways around it and most of these would not pass their PCI compliance anyhow with a PHP version that out of date.

There are also quite a few options for these users.

For RedHat/CentOS users:
1. Use Zend Server Community Edition
2. Use a different repository: Remi (http://blog.famillecollet.com/pages/Config-en) or iUSCommunity (http://iuscommunity.org/)
3. Compile a new version or find a different package elsewhere.

For Debian users:
1. Use Zend Server Community Edition
2. Use a different repository: Dotdeb (http://www.dotdeb.org/)
3. Compile a new version or find a different package elsewhere.

I'm actually not certain how many users are stuck at those versions right now; it might be good to look at some of the hosts out there as well.

Regards,

Mike


On Fri, Feb 1, 2013 at 10:01 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
Originally, we chose 5.3.3 as that was the version being used in LTS
versions of popular distros. Since that decision was made, however, I
believe both RHEL and Ubuntu have moved to a later 5.3 version, which
means it may be a moot point.

Anybody with hard data? or grids showing the versions by distro?

On Fri, Feb 1, 2013 at 12:00 PM, Demian Katz <[hidden email]> wrote:
> Does anyone keep charts of which PHP versions are distributed with which
> versions of OSes?  My first inclination would be to bump the minimum version
> -- the ArrayObject insanity caused me a lot of problems early in my work
> with ZF2 -- but if there's data indicating that 5.3.5 is significantly less
> common than 5.3.3, that might be an argument to live with the status quo.
>
> - Demian
> ________________________________
> From: Mike Willbanks [[hidden email]]
> Sent: Friday, February 01, 2013 12:55 PM
> To: Zend Framework Contributors
> Subject: [zf-contributors] Minimum PHP Version to 5.3.5?
>
> Hey All,
>
> So; we've had a few issues due to ArrayObject's specifically in the session
> code; basically there is no workaround to this; you might see errors
> stating: "Indirect modification to overloaded property".  This is because
> ArrayObject does not allow offsetGet to return by reference.  Fortunately;
> ArrayAccess allows us to do that BUT it only allows us to return it by
> reference in versions greater than 5.3.3.
>
> We really only have a few options here but here they are:
> 1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we
> basically create our own version of ArrayObject (actually have this working
> already and it fixes the "Indirect modification to overloaded property" in
> Zend\Session\Container).  For more on the code bits see:
> https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object
>
> 2. Rewrite anything that currently uses ArrayObject that needs to modify
> parameters to something more feasible.  - Really not a great choice.
>
> 3. Do nothing; keep it the same and blame PHP for the ArrayObject
> implementation.  This means continued bug reports on anything using
> ArrayObject or ArrayAccess that needs to manipulate multi-dimensional
> properties (yes; this happens way more than you might think).
>
> Regards,
>
> Mike



--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc






Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

Tomáš Fejfar
From my point of view - the version bump is not a big problem. But it MUST NOT bump ahead of major linux distros version. 

Tomas Fejfar, w3w.cz

twitter: @tomasfejfar
email: [hidden email]
www: http://www.tomasfejfar.cz



On Mon, Feb 4, 2013 at 5:31 PM, Anthony Shireman <[hidden email]> wrote:
It seems that any direction (increasing the version required or rewriting the framework) will involve a bit of work and I guess the question is who will do the work and where will the biggest benefit be? As Matthew said, ZF2 was targeted at 5.3.3 and since then PHP has been upgraded to 5.3.21. The 5.3 series is entering it's end of life in March. I'd like to say that upping the version requirement shouldn't be a bad idea even over the course of the life of ZF2. The minor version increases provide improved performance, stability and security so choosing to not utilize them seems like a poor choice. Changing the framework to fix an issue that's already been fixed seems like a waste of the framework developers time. Bumping the minimum version to just above what's required to fix the issue seems like the best thing to do and requires minimal effort on the framework developers and helps out the majority of the users. (Side note: Has a recent "What version of PHP are you using poll happened?" Should it?) It doesn't seem like a huge jump for those that are still using 5.3.3 to go to 5.3.5 considering that the distros that are still at that version seem to be in the minority. Anyone who is in an environment that just *cannot* go from 5.3.3->5.3.5 with fairly minimal effort?


On Mon, Feb 4, 2013 at 6:53 AM, Zachary Burnham <[hidden email]> wrote:
This was meant to go to the full list, sorry Mike.  Thanks, Gmail.

On Mon, Feb 4, 2013 at 9:51 AM, Zachary Burnham <[hidden email]> wrote:
My two cents:

It is not reasonable to ask someone to upgrade past what their distribution/OS offers in terms of a php package.  When people evaluate the use of a given framework, and they look at the minimum requirements, and find that CentOS or RHEL, for example, does not meet them, they will not use the framework, instead of following any instructions about how to install an alternative package.  I am fortunate in that I am able to install virtually any package that I wish on our servers, but the vast majority of developers do not have that freedom, either due to corporate procedures, a lack of systems administration experience, or inadequate resources; very often, all three. 

If the solution is to work around it in the code (which I understand is a lot of work) or prevent a large number of people from being able to use the framework, that's not even close for me.

Z



On Fri, Feb 1, 2013 at 4:27 PM, Mike Willbanks <[hidden email]> wrote:
Yes I know there are security patches; it also all depends on who does your PCI compliance and if that is good enough or not.  In the case I am in; we have to be above certain patch releases (i remember we had severs to upgraded from like PHP 5.3.6 to something else.  Either way; we do face fundamental issues:

Overall; we're going to start hitting larger and larger issues as time moves forward and the issues comes down to:
1. We likely break BC because we need to fix a bug due to a bug in particular PHP versions
2. We ignore the bug and do not resolve it until we are able to up the minimum version requirements

#1 may not __always__ break BC but in the majority of cases there will be slight BC breaks due to it.  It is certainly unfortunate.

At this point; there are two things that should __never__ be used in the framework that need to do array manipulation (aka unset being the largest): ArrayObject and ArrayAccess.  ArrayAccess could be lifted after 5.3.4 BUT ArrayObject contains a fundamental problem and should __only__ be used if and only if the object is going to be for: single dimension arrays OR reading only.

Unfortunately at this point both are utilized in various places in the framework and I had to do a ton of work to make an ArrayObject manually to attempt to get around some issues but it has to leverage ArrayAccess; well our minimum version requirements are 5.3.3.  This means that we would have to live with the bugs for those users and then provide alternative classes to load in the event the user is above 5.3.4 - basically going into dynamic loading of classes which do have performance penalties. 

Regards,

Mike

On Fri, Feb 1, 2013 at 12:22 PM, Zdenek Machek <[hidden email]> wrote:
Hi,
I don't think this is exactly true.

For example Debian Squeeze has php5 (5.3.3-7+squeeze14)  -7+squeeze14 means security patches, means of course it is PCI compliant.
It doesn't means fixed other bugs, which is sometimes very annoying.

But lot's of people are stacked with hosting where you have to use just standard repository, means you have to stay with php 5.3.3
I think it would be mistake to require 5.3.5, when major Linux distributions at the moment provide just 5.3.3.

Regards

Zdenek Machek


On 1 February 2013 19:16, Mike Willbanks <[hidden email]> wrote:
Looks like from distrowatch that php 5.3.3 is on RedHat, CentOS and Debian from the major distributions (looking at most of the current ones).  Fortunately there are easy ways around it and most of these would not pass their PCI compliance anyhow with a PHP version that out of date.

There are also quite a few options for these users.

For RedHat/CentOS users:
1. Use Zend Server Community Edition
2. Use a different repository: Remi (http://blog.famillecollet.com/pages/Config-en) or iUSCommunity (http://iuscommunity.org/)
3. Compile a new version or find a different package elsewhere.

For Debian users:
1. Use Zend Server Community Edition
2. Use a different repository: Dotdeb (http://www.dotdeb.org/)
3. Compile a new version or find a different package elsewhere.

I'm actually not certain how many users are stuck at those versions right now; it might be good to look at some of the hosts out there as well.

Regards,

Mike


On Fri, Feb 1, 2013 at 10:01 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
Originally, we chose 5.3.3 as that was the version being used in LTS
versions of popular distros. Since that decision was made, however, I
believe both RHEL and Ubuntu have moved to a later 5.3 version, which
means it may be a moot point.

Anybody with hard data? or grids showing the versions by distro?

On Fri, Feb 1, 2013 at 12:00 PM, Demian Katz <[hidden email]> wrote:
> Does anyone keep charts of which PHP versions are distributed with which
> versions of OSes?  My first inclination would be to bump the minimum version
> -- the ArrayObject insanity caused me a lot of problems early in my work
> with ZF2 -- but if there's data indicating that 5.3.5 is significantly less
> common than 5.3.3, that might be an argument to live with the status quo.
>
> - Demian
> ________________________________
> From: Mike Willbanks [[hidden email]]
> Sent: Friday, February 01, 2013 12:55 PM
> To: Zend Framework Contributors
> Subject: [zf-contributors] Minimum PHP Version to 5.3.5?
>
> Hey All,
>
> So; we've had a few issues due to ArrayObject's specifically in the session
> code; basically there is no workaround to this; you might see errors
> stating: "Indirect modification to overloaded property".  This is because
> ArrayObject does not allow offsetGet to return by reference.  Fortunately;
> ArrayAccess allows us to do that BUT it only allows us to return it by
> reference in versions greater than 5.3.3.
>
> We really only have a few options here but here they are:
> 1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we
> basically create our own version of ArrayObject (actually have this working
> already and it fixes the "Indirect modification to overloaded property" in
> Zend\Session\Container).  For more on the code bits see:
> https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object
>
> 2. Rewrite anything that currently uses ArrayObject that needs to modify
> parameters to something more feasible.  - Really not a great choice.
>
> 3. Do nothing; keep it the same and blame PHP for the ArrayObject
> implementation.  This means continued bug reports on anything using
> ArrayObject or ArrayAccess that needs to manipulate multi-dimensional
> properties (yes; this happens way more than you might think).
>
> Regards,
>
> Mike



--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc







Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

zburnham
Just so everyone's on the same page, RHEL is indeed stuck at 5.3.3 at the moment, in the latest release:

http://distrowatch.com/table.php?distribution=redhat

On Mon, Feb 4, 2013 at 12:14 PM, Tomáš Fejfar <[hidden email]> wrote:
From my point of view - the version bump is not a big problem. But it MUST NOT bump ahead of major linux distros version. 

Tomas Fejfar, w3w.cz

twitter: @tomasfejfar
email: [hidden email]
www: http://www.tomasfejfar.cz



On Mon, Feb 4, 2013 at 5:31 PM, Anthony Shireman <[hidden email]> wrote:
It seems that any direction (increasing the version required or rewriting the framework) will involve a bit of work and I guess the question is who will do the work and where will the biggest benefit be? As Matthew said, ZF2 was targeted at 5.3.3 and since then PHP has been upgraded to 5.3.21. The 5.3 series is entering it's end of life in March. I'd like to say that upping the version requirement shouldn't be a bad idea even over the course of the life of ZF2. The minor version increases provide improved performance, stability and security so choosing to not utilize them seems like a poor choice. Changing the framework to fix an issue that's already been fixed seems like a waste of the framework developers time. Bumping the minimum version to just above what's required to fix the issue seems like the best thing to do and requires minimal effort on the framework developers and helps out the majority of the users. (Side note: Has a recent "What version of PHP are you using poll happened?" Should it?) It doesn't seem like a huge jump for those that are still using 5.3.3 to go to 5.3.5 considering that the distros that are still at that version seem to be in the minority. Anyone who is in an environment that just *cannot* go from 5.3.3->5.3.5 with fairly minimal effort?


On Mon, Feb 4, 2013 at 6:53 AM, Zachary Burnham <[hidden email]> wrote:
This was meant to go to the full list, sorry Mike.  Thanks, Gmail.

On Mon, Feb 4, 2013 at 9:51 AM, Zachary Burnham <[hidden email]> wrote:
My two cents:

It is not reasonable to ask someone to upgrade past what their distribution/OS offers in terms of a php package.  When people evaluate the use of a given framework, and they look at the minimum requirements, and find that CentOS or RHEL, for example, does not meet them, they will not use the framework, instead of following any instructions about how to install an alternative package.  I am fortunate in that I am able to install virtually any package that I wish on our servers, but the vast majority of developers do not have that freedom, either due to corporate procedures, a lack of systems administration experience, or inadequate resources; very often, all three. 

If the solution is to work around it in the code (which I understand is a lot of work) or prevent a large number of people from being able to use the framework, that's not even close for me.

Z



On Fri, Feb 1, 2013 at 4:27 PM, Mike Willbanks <[hidden email]> wrote:
Yes I know there are security patches; it also all depends on who does your PCI compliance and if that is good enough or not.  In the case I am in; we have to be above certain patch releases (i remember we had severs to upgraded from like PHP 5.3.6 to something else.  Either way; we do face fundamental issues:

Overall; we're going to start hitting larger and larger issues as time moves forward and the issues comes down to:
1. We likely break BC because we need to fix a bug due to a bug in particular PHP versions
2. We ignore the bug and do not resolve it until we are able to up the minimum version requirements

#1 may not __always__ break BC but in the majority of cases there will be slight BC breaks due to it.  It is certainly unfortunate.

At this point; there are two things that should __never__ be used in the framework that need to do array manipulation (aka unset being the largest): ArrayObject and ArrayAccess.  ArrayAccess could be lifted after 5.3.4 BUT ArrayObject contains a fundamental problem and should __only__ be used if and only if the object is going to be for: single dimension arrays OR reading only.

Unfortunately at this point both are utilized in various places in the framework and I had to do a ton of work to make an ArrayObject manually to attempt to get around some issues but it has to leverage ArrayAccess; well our minimum version requirements are 5.3.3.  This means that we would have to live with the bugs for those users and then provide alternative classes to load in the event the user is above 5.3.4 - basically going into dynamic loading of classes which do have performance penalties. 

Regards,

Mike

On Fri, Feb 1, 2013 at 12:22 PM, Zdenek Machek <[hidden email]> wrote:
Hi,
I don't think this is exactly true.

For example Debian Squeeze has php5 (5.3.3-7+squeeze14)  -7+squeeze14 means security patches, means of course it is PCI compliant.
It doesn't means fixed other bugs, which is sometimes very annoying.

But lot's of people are stacked with hosting where you have to use just standard repository, means you have to stay with php 5.3.3
I think it would be mistake to require 5.3.5, when major Linux distributions at the moment provide just 5.3.3.

Regards

Zdenek Machek


On 1 February 2013 19:16, Mike Willbanks <[hidden email]> wrote:
Looks like from distrowatch that php 5.3.3 is on RedHat, CentOS and Debian from the major distributions (looking at most of the current ones).  Fortunately there are easy ways around it and most of these would not pass their PCI compliance anyhow with a PHP version that out of date.

There are also quite a few options for these users.

For RedHat/CentOS users:
1. Use Zend Server Community Edition
2. Use a different repository: Remi (http://blog.famillecollet.com/pages/Config-en) or iUSCommunity (http://iuscommunity.org/)
3. Compile a new version or find a different package elsewhere.

For Debian users:
1. Use Zend Server Community Edition
2. Use a different repository: Dotdeb (http://www.dotdeb.org/)
3. Compile a new version or find a different package elsewhere.

I'm actually not certain how many users are stuck at those versions right now; it might be good to look at some of the hosts out there as well.

Regards,

Mike


On Fri, Feb 1, 2013 at 10:01 AM, Matthew Weier O'Phinney <[hidden email]> wrote:
Originally, we chose 5.3.3 as that was the version being used in LTS
versions of popular distros. Since that decision was made, however, I
believe both RHEL and Ubuntu have moved to a later 5.3 version, which
means it may be a moot point.

Anybody with hard data? or grids showing the versions by distro?

On Fri, Feb 1, 2013 at 12:00 PM, Demian Katz <[hidden email]> wrote:
> Does anyone keep charts of which PHP versions are distributed with which
> versions of OSes?  My first inclination would be to bump the minimum version
> -- the ArrayObject insanity caused me a lot of problems early in my work
> with ZF2 -- but if there's data indicating that 5.3.5 is significantly less
> common than 5.3.3, that might be an argument to live with the status quo.
>
> - Demian
> ________________________________
> From: Mike Willbanks [[hidden email]]
> Sent: Friday, February 01, 2013 12:55 PM
> To: Zend Framework Contributors
> Subject: [zf-contributors] Minimum PHP Version to 5.3.5?
>
> Hey All,
>
> So; we've had a few issues due to ArrayObject's specifically in the session
> code; basically there is no workaround to this; you might see errors
> stating: "Indirect modification to overloaded property".  This is because
> ArrayObject does not allow offsetGet to return by reference.  Fortunately;
> ArrayAccess allows us to do that BUT it only allows us to return it by
> reference in versions greater than 5.3.3.
>
> We really only have a few options here but here they are:
> 1. Bump the minimum version up to 5.3.5 (5.3.4 had a nasty bit) and we
> basically create our own version of ArrayObject (actually have this working
> already and it fixes the "Indirect modification to overloaded property" in
> Zend\Session\Container).  For more on the code bits see:
> https://github.com/mwillbanks/zf2/compare/hotfix;session-container-array-object
>
> 2. Rewrite anything that currently uses ArrayObject that needs to modify
> parameters to something more feasible.  - Really not a great choice.
>
> 3. Do nothing; keep it the same and blame PHP for the ArrayObject
> implementation.  This means continued bug reports on anything using
> ArrayObject or ArrayAccess that needs to manipulate multi-dimensional
> properties (yes; this happens way more than you might think).
>
> Regards,
>
> Mike



--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc








Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

Ben Scholzen 'DASPRiD'
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

Mike Willbanks

On 04.02.2013 20:18, Zachary Burnham wrote:
> Just so everyone's on the same page, RHEL is indeed stuck at 5.3.3 at
> the moment, in the latest release:
>
> http://distrowatch.com/table.php?distribution=redhat

The question is if RHEL backports bug- and security fixes or if that's
actually stock 5.3.3. Eventually though my opinion is that we shouldn't
fix upstream bugs which are already fixed.

Seriously, if a distribution is not able to keep software maintained
with bug- and security fixes, there's clearly something wrong with the
distribution, and this one itself should be considered risky and not
usable for production.

I agree; unfortunately they only backport security related bug fixes.  It is not stock which creates a whole different set of issues.  Honestly; distribution provided packages frustrate me so badly.  At a minimum I wish they would just work with Zend and incorporate their RPMs for zend server community edition as they at least keep them fairly updated.  Maybe not the most recent version of PHP but it does have the latest 5.3.  

I guess we will start doing conditionals to load different classes so we can fix some stupid bugs but I guess the more we need to do that the crappier it will become to maintain. 

Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

Antoine Hedgecock
I fully agree with DASRPID we should not fix bugs that have been fixed upstream it's unnecessary work when we have much better things we could spend our time on.

On Feb 4, 2013, at 8:35 PM, Mike Willbanks <[hidden email]> wrote:

> I guess we will start doing conditionals to load different classes so we can fix some stupid bugs but I guess the more we need to do that the crappier it will become to maintain.

I honestly think thats a terrible idea!
Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

zburnham
In reply to this post by Ben Scholzen 'DASPRiD'
Lots and lots and lots of people use RHEL.  It's the distribution that you present to the non-technical people who write the checks when you want them to understand that it's not just hippy open source tree hugging crap, it has actual value.  It provides someone to yell at when it breaks, instead of the faceless hordes that (they think) maintain most distros. 

There is what should be (that the mundanes would understand that we're being paid to do a job and we should be allowed to do it as we see fit) and there is what is (where idiots rule.)  We are not going to change Red Hat's behavior, and lots of people are going to continue to use RHEL because they have to. 

We should be pragmatic here.  This isn't a battle we want to pick, I think.

On Mon, Feb 4, 2013 at 2:31 PM, Ben Scholzen 'DASPRiD' <[hidden email]> wrote:
On 04.02.2013 20:18, Zachary Burnham wrote:
> Just so everyone's on the same page, RHEL is indeed stuck at 5.3.3 at
> the moment, in the latest release:
>
> http://distrowatch.com/table.php?distribution=redhat

The question is if RHEL backports bug- and security fixes or if that's
actually stock 5.3.3. Eventually though my opinion is that we shouldn't
fix upstream bugs which are already fixed.

Seriously, if a distribution is not able to keep software maintained
with bug- and security fixes, there's clearly something wrong with the
distribution, and this one itself should be considered risky and not
usable for production.

--
Ben Scholzen 'DASPRiD'
Community Review Team Member | [hidden email]
Zend Framework               | http://www.dasprids.de

Reply | Threaded
Open this post in threaded view
|

Re: Minimum PHP Version to 5.3.5?

zburnham
In reply to this post by Antoine Hedgecock
Idealism is good and all, but at the end of the day, this is going to keep people from using ZF2.  It's not right, but it is true.  Yes, it sucks, but it's not going to change, so instead of beating our heads against the wall that we're insisting shouldn't be there, maybe we can do something constructive.  Even the energy we're expending arguing about it is wasteful and non-productive.  We can bounce around the capsule for 10 minutes, but we'll still be in a crippled command module hurtling around the moon.

On Mon, Feb 4, 2013 at 2:39 PM, Antoine Hedgecock <[hidden email]> wrote:
I fully agree with DASRPID we should not fix bugs that have been fixed upstream it's unnecessary work when we have much better things we could spend our time on.

On Feb 4, 2013, at 8:35 PM, Mike Willbanks <[hidden email]> wrote:

> I guess we will start doing conditionals to load different classes so we can fix some stupid bugs but I guess the more we need to do that the crappier it will become to maintain.

I honestly think thats a terrible idea!

1234