|
|
1234
|
|
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:
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
|
|
|
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:
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
|
|
|
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?
|
|
Administrator
|
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
|
|
|
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
3. Compile a new version or find a different package elsewhere.
For Debian users: 1. Use Zend Server Community Edition
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
|
|
|
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
|
|
|
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
|
|
|
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
3. Compile a new version or find a different package elsewhere.
For Debian users: 1. Use Zend Server Community Edition
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 |
|
|
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.
|
|
|
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.
|
|
|
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.
|
|
|
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?
|
|
|
From my point of view - the version bump is not a big problem. But it MUST NOT bump ahead of major linux distros version.
|
|
|
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.
|
|
|
CONTENTS DELETED
The author has deleted this message.
|
|
|
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!
|
|
|
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:
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
|
|
|
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.
|
1234
|
Locked
