First, I agree with the RHEL / LTS distro arguments, and can see that having a negative effect on these companies. My gut reaction is to say no, we should respect the version we committed to originally, despite the cost (hey, we can't use traits either... too bad). I can personally confirm that many companies specifically choose Zend Framework because of the reliability on these types of matters (more-so backwards compatibility breaks, but PHP version support plays a large role as well).
That said, due to the ZF policy of backporting security fixes to previous minor version releases, which matches that of the distributions being cited here, I don't actually see bumping the PHP version requirement as a problem. These enterprise users will simply have to be feature-frozen and only receive minor version updates when a security fix is backported, period. Missing out on new features and (non-critical) bugfixes *after* such a change is a cost they have already accepted as part of their policy to limit themselves strictly to distribution-provided packages. So, ultimately, I can't say I'd actually be upset either way. All of my clients who are using enterprise / LTS distributions will still be fine to use all of the ZF2 features they've come to depend on up until this point, and we'll still be able to update their ZF2 minor version when/if future security fixes are released. If such a change meant that enterprise / LTS distro users would be unable to get critical security fixes, then I'd strongly be -1 to this, but that is simply not the case here. -- *Evan Coury, ZCE* http://blog.evan.pro/ On Tue, Nov 5, 2013 at 12:34 PM, Matthew Weier O'Phinney <matt...@zend.com>wrote: > Hey, all -- > > We're running into a few situations where bumping the minimum required > PHP version for ZF2 would be useful; in fact, there's at least one > situation where staying with 5.3.3 actually prevents progress on a few > issues. > > The specific issue we have is that, until 5.3.9, PHP did not allow the > following: > > interface Foo > { > public function send(); > } > > interface Bar > { > public function send(); > } > > class FooBar implements Foo, Bar > { > public function send() > { > // do something > } > } > > Essentially, implementing multiple interfaces that define the same > method, using the same signature. > Prior to 5.3.9, this raises an E_FATAL. From 5.3.9 forward, it works. > > Having this would allow us to fix a situation with the way translation > works across components; not having it means we're stuck with some of > those problems. > > There are other issues as well: ArrayObject has had a lively history > of malfunctioning with 5.3 and 5.4, and there are some odd behaviors > in the object model as well that have been corrected starting in 5.3.7 > and up. > > Considering PHP 5.3 has already reached end of life status > (http://php.net/archive/2013.php#id2013-07-11-1), upping the minimum > version seems like "a good idea." > > My question, then is: > > - Should we up the minimum required PHP version for ZF2? > - If your answer was "no", why not? > - If your answer was "yes", what version should become the next > minimum supported PHP version? Why? > > NOTE: we are not announcing that we will up the minimum required > version at this time; I'm soliciting feedback so we can make a > decision. > > Thanks in advance! > > -- > Matthew Weier O'Phinney > Project Lead | matt...@zend.com > Zend Framework | http://framework.zend.com/ > PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc >
