# [VOTE] Integrating Zend Optimizer+ into the PHP distribution - Thread: https://externals.io/message/66277 - Original archive: https://news-web.php.net/php.internals/66277 - Started by Zeev Suraski on 2013-02-27T16:12:42+00:00 - Messages: 110 - Page 1 of 5: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/66277.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #66277 — Zeev Suraski — 2013-02-27T16:12:42+00:00 URL: https://externals.io/message/66277#66277 Based on the overwhelming response, the vote is now open J https://wiki.php.net/rfc/optimizerplus Voting ends March 7th. Zeev --- ## #66278 — Alberto Viana — 2013-02-27T16:24:00+00:00 URL: https://externals.io/message/66277#66278 · In reply to: #66277 +1 > Based on the overwhelming response, the vote is now open J > > > > https://wiki.php.net/rfc/optimizerplus > > > > Voting ends March 7th. > > > > Zeev > -- Alberto Guimarães Viana E-mail: albertogviana@gmail.com http://blog.albertoviana.com "Uma pessoa inteligente resolve um problema, um sábio o previne." Albert Einstein --- ## #66279 — Anthony Ferrara — 2013-02-27T16:58:56+00:00 URL: https://externals.io/message/66277#66279 · In reply to: #66278 Zeev et al, I just want to put my justification for the "only if no delay" vote. I voted that way because we're already at a significant delay. If this vote was a month ago when O+ was suggested first, I would definitely have voted for "delay". In fact IIRC I proposed a delay back then. But after a month, I think delaying much further would be imprudent. Just my $0.02 Anthony On Wed, Feb 27, 2013 at 11:24 AM, Alberto Viana wrote: > +1 > > > > > > […] > > > > -- > Alberto Guimarães Viana > E-mail: albertogviana@gmail.com > http://blog.albertoviana.com > > "Uma pessoa inteligente resolve um problema, um sábio o previne." Albert > Einstein --- ## #66294 — Zeev Suraski — 2013-02-27T19:31:48+00:00 URL: https://externals.io/message/66277#66294 · In reply to: #66279 > Zeev et al, > > I just want to put my justification for the "only if no delay" vote. I voted that way because we're already at a significant delay. If this vote was a month ago when O+ was suggested first, I would definitely have voted for "delay". In fact IIRC I proposed a delay back then. But after a month, I think delaying much further would be imprudent. > Fair enough! Here's mine for delaying: I believe our users will much appreciate a release with an opcode cache that's several months delayed vs. one that's without an opcode cache several months early. If the 5.4 adoption rate (or complete lack thereof) is any indication - very few are eagerly waiting for 5.5. In fact, in a year's time, when we all gear up to release 5.6 (based on current frequency) - 5.5 is almost guaranteed to have next to no traction in our userbase. A bundled opcode cache might be the killer feature that makes the difference. FWIW I think we should actually reconsider even striving for a yearly release cycle, but that's another story... Zeev --- ## #66299 — Ferenc Kovacs — 2013-02-27T21:01:29+00:00 URL: https://externals.io/message/66277#66299 · In reply to: #66277 > Based on the overwhelming response, the vote is now open J > > > > https://wiki.php.net/rfc/optimizerplus > > > > Voting ends March 7th. > > > > Zeev > Hi Zeev, I'm not sure that the current options covering all cases. How should one vote if he/she thinks that this should go into the next release after 5.5? Currently their only option would be to vote for no, which isn't doesn't really the same thing. Personally I would prefer roll out 5.5 without O+, but release it in PECL for all supported branches and move it for core in master(which means having it in 5.6/6.0/whatever will be the next version). Currently I don't have an option which I'm comfortable with, maybe there are others in the similar situation. ps: I really love what you guys did with opensourcing it, but I just think that it is too late for 5.5 and I think that it is better to stick to the original roadmap, instead of having a 6 months delay just to ship the O+ in the core 6months earlier than the next version after 5.5 would be shipped if we would have followed the yearly release plan in the first place. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #66301 — Rasmus Lerdorf — 2013-02-27T21:19:44+00:00 URL: https://externals.io/message/66277#66301 · In reply to: #66299 > ps: I really love what you guys did with opensourcing it, but I just think > that it is too late for 5.5 and I think that it is better to stick to the > original roadmap, instead of having a 6 months delay just to ship the O+ in > the core 6months earlier than the next version after 5.5 would be shipped > if we would have followed the yearly release plan in the first place. This is where I think we have a big disconnect. This yearly release plan is meaningless for most people because there is no way the current opcode cache situation can keep up with that. PHP 5.4 wasn't really released until APC was mostly stable with it which was 6+ months after the release. This is the most urgent thing we need to fix in the PHP world. Everything else in this 5.5 release is irrelevant as far as I am concerned and we are pushing because of an arbitrary deadline that is tighter than most previous releases. In order to actually get the project onto a feasible yearly release cycle we need to pool the few resources we do have around a single opcode cache implementation and push it as the one and only option as it will force each new shiny feature to tackle opcode support from day one as opposed to circling back around to it as an afterthought as has happened so often. And no, time has proven that this can't be done by having it in pecl. It didn't work for APC despite me trying to push that and I don't see why it would work for O+. Note that if you take the PHP 5.4 release date as the date APC started working reliably with it, we are well within the yearly release cycle and not actually late at all. -Rasmus --- ## #66302 — Nikita Popov — 2013-02-27T21:30:01+00:00 URL: https://externals.io/message/66277#66302 · In reply to: #66301 > > > > […] > think > > […] > in > > […] > > This is where I think we have a big disconnect. This yearly release plan > is meaningless for most people because there is no way the current > opcode cache situation can keep up with that. PHP 5.4 wasn't really > released until APC was mostly stable with it which was 6+ months after > the release. This is the most urgent thing we need to fix in the PHP > world. Everything else in this 5.5 release is irrelevant as far as I am > concerned and we are pushing because of an arbitrary deadline that is > tighter than most previous releases. > > In order to actually get the project onto a feasible yearly release > cycle we need to pool the few resources we do have around a single > opcode cache implementation and push it as the one and only option as it > will force each new shiny feature to tackle opcode support from day one > as opposed to circling back around to it as an afterthought as has > happened so often. And no, time has proven that this can't be done by > having it in pecl. It didn't work for APC despite me trying to push that > and I don't see why it would work for O+. > All these are really great arguments for including O+ ... in PHP 5.6. O+ is already compatible with PHP 5.5 and as we're just days away from feature freeze this will stay so til the final release ("stay so" as in requiring only minor adjustments). For 5.6 it can then be merged so that we'll be forced to maintain the opcode cache along the way when doing new engine changes. Nikita --- ## #66303 — Adam Jon Richardson — 2013-02-27T21:40:58+00:00 URL: https://externals.io/message/66277#66303 · In reply to: #66302 > > > All these are really great arguments for including O+ ... in PHP 5.6. O+ is > already compatible with PHP 5.5 and as we're just days away from feature > freeze this will stay so til the final release ("stay so" as in requiring > only minor adjustments). For 5.6 it can then be merged so that we'll be > forced to maintain the opcode cache along the way when doing new engine > changes. > > Nikita What will people use as an opcode cache for 5.4? Adam --- ## #66304 — Ferenc Kovacs — 2013-02-27T21:41:25+00:00 URL: https://externals.io/message/66277#66304 · In reply to: #66301 > > > > […] > think > > […] > in > > […] > > This is where I think we have a big disconnect. This yearly release plan > is meaningless for most people because there is no way the current > opcode cache situation can keep up with that. PHP 5.4 wasn't really > released until APC was mostly stable with it which was 6+ months after > the release. This is the most urgent thing we need to fix in the PHP > world. Everything else in this 5.5 release is irrelevant as far as I am > concerned and we are pushing because of an arbitrary deadline that is > tighter than most previous releases. > > In order to actually get the project onto a feasible yearly release > cycle we need to pool the few resources we do have around a single > opcode cache implementation and push it as the one and only option as it > will force each new shiny feature to tackle opcode support from day one > as opposed to circling back around to it as an afterthought as has > happened so often. And no, time has proven that this can't be done by > having it in pecl. It didn't work for APC despite me trying to push that > and I don't see why it would work for O+. > > Note that if you take the PHP 5.4 release date as the date APC started > working reliably with it, we are well within the yearly release cycle > and not actually late at all. > > -Rasmus > as Nikita mentioned those who can and willing to upgrade will be able to use O+ for 5.5 even if it comes in pecl, as it is already in a good shape for 5.5. adding it to the core in master will also make sure that there are no future disconnects between the new features and the opcode cache support. we discussed this on irc previously so I'm pretty sure that we have to agree to disagree here, as none of us seeming to change his opinion on the matter, but I hope we can at least provide some more expressive options for the vote. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #66305 — Adam Jon Richardson — 2013-02-27T21:43:13+00:00 URL: https://externals.io/message/66277#66305 · In reply to: #66303 > > > […] > > What will people use as an opcode cache for 5.4? > > Adam Sorry, typo, I meant to say 5.5. Adam --- ## #66306 — Nikita Popov — 2013-02-27T21:45:10+00:00 URL: https://externals.io/message/66277#66306 · In reply to: #66305 On Wed, Feb 27, 2013 at 10:43 PM, Adam Jon Richardson wrote: > On Wed, Feb 27, 2013 at 4:40 PM, Adam Jon Richardson > wrote: > > […] > wrote: > > […] > wrote: > > […] > O+ is > > […] > requiring > > […] > > Sorry, typo, I meant to say 5.5. > > Not sure I understand the question. O+ is compatible with 5.5, so you can use that if you like. Just install it as an ext. Just like you would have done with APC. Nikita --- ## #66307 — Adam Jon Richardson — 2013-02-27T22:02:48+00:00 URL: https://externals.io/message/66277#66307 · In reply to: #66306 > > […] > Not sure I understand the question. O+ is compatible with 5.5, so you can > use that if you like. Just install it as an ext. Just like you would have > done with APC. > > Nikita More than ANY other language feature, having an integrated opcode cache (i.e., one that isn't playing catch up but is treated as a core requirement) would help people adopt PHP 5.5 in a timely manner. APC was buggy for quite a while after the launch of 5.4 (and know those who worked on it worked very hard, and I actually took a look at some of the bugs, but APC seemed to be beyond my skill set.) Knowing that O+ is compatible with 5.5 doesn't give me confidence that it will work well. What is the harm in delaying PHP 5.5 and trying to integrate O+ into the release? Adam --- ## #66308 — Pierre Joye — 2013-02-27T22:16:31+00:00 URL: https://externals.io/message/66277#66308 · In reply to: #66301 > > This is where I think we have a big disconnect. This yearly release plan > is meaningless for most people because there is no way the current > opcode cache situation can keep up with that. PHP 5.4 wasn't really > released until APC was mostly stable with it which was 6+ months after > the release. That's why having a builtin opcode cache should be a long term goal. And that's why it will be done this way. All other ways failed. > In order to actually get the project onto a feasible yearly release > cycle we need to pool the few resources we do have around a single > opcode cache implementation and push it as the one and only option as it > will force each new shiny feature to tackle opcode support from day one Exactly. Now, about the yearly release, every single person I talked to love it and want us to keep with this cycle, as well as the more frequent bugs fixes releases. One thing we have to slightly change is to push too many new features in each of them, but we will get there. cheers, -- Pierre @pierrejoye --- ## #66309 — Bob Weinand — 2013-02-27T22:20:30+00:00 URL: https://externals.io/message/66277#66309 · In reply to: #66299 Am 27.2.2013 um 22:01 schrieb Ferenc Kovacs : > I'm not sure that the current options covering all cases. > How should one vote if he/she thinks that this should go into the next > release after 5.5? > Currently their only option would be to vote for no, which isn't doesn't > really the same thing. > Personally I would prefer roll out 5.5 without O+, but release it in PECL > for all supported branches and move it for core in master(which means > having it in 5.6/6.0/whatever will be the next version). > Currently I don't have an option which I'm comfortable with, maybe there > are others in the similar situation. > > ps: I really love what you guys did with opensourcing it, but I just think > that it is too late for 5.5 and I think that it is better to stick to the > original roadmap, instead of having a 6 months delay just to ship the O+ in > the core 6months earlier than the next version after 5.5 would be shipped > if we would have followed the yearly release plan in the first place. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu I don't see any reason why we should even have the idea to integrate O+ when it's possible to do it without any delay. Where is the big advantage of letting customers waiting longer than needed? (Yes, they can install it from PECL, but this is a suboptimal solution as it is no reason why installing PHP 5.5) A major release has to have a sense. There are generators... A finally keyword... list in foreach...!??? Shiny new features is the right name for this. Nothing you need. It may clean up code to use them, but this is not important enough to update, deal with the deprecated mysql extension, test the environment if everything works with it. Also a lot of users have PHP versions older than PHP5.4. Some of them may still relay on removed features like these magic_quotes etc. They all have to change their code for an update. If there is nothing really important like a faster opcode cache (faster than APC), less crashes under high load (we have sometimes these unreproducible reports in the bug list...), they don't matter about it. Please name me a few good reasons what sense releasing a PHP version nobody (who is not a developer) cares about it makes. Bob (p.s.: I like also these shiny features, but if they'd be so important, you could also install from trunk. (That's what I do.) And don't tell me the myth that only releases can be stable. Only a few weeks after the introduction of a new feature it is often as stable as in the future major version.) --- ## #66312 — Pierre Joye — 2013-02-28T06:53:46+00:00 URL: https://externals.io/message/66277#66312 · In reply to: #66277 > Based on the overwhelming response, the vote is now open J > > > > https://wiki.php.net/rfc/optimizerplus > > > > Voting ends March 7th. ok, given the total lack of answers, mistakes and misleading wording in the RFC and lack of releases in PECL (which is a pre requise since quite some time to get in core), I'd to vote -1 for now. It will surely won't change anything but I stand to what we discuss. -- Pierre @pierrejoye --- ## #66316 — Kalle Sommer Nielsen — 2013-02-28T08:05:10+00:00 URL: https://externals.io/message/66277#66316 · In reply to: #66312 Den 28/02/2013 kl. 07.53 skrev Pierre Joye : > > ok, given the total lack of answers, mistakes and misleading wording > in the RFC and lack of releases in PECL (which is a pre requise since > quite some time to get in core), I'd to vote -1 for now. My reasons exactly for now, while it is tempting to vote against our own agreements -K --- ## #66318 — Zeev Suraski — 2013-02-28T10:21:22+00:00 URL: https://externals.io/message/66277#66318 · In reply to: #66308 > -----Original Message----- > From: Pierre Joye [mailto:pierre.php@gmail.com] > Sent: Thursday, February 28, 2013 12:17 AM > To: Rasmus Lerdorf > Cc: Ferenc Kovacs; Zeev Suraski; PHP Developers Mailing List > Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP > distribution > > Now, about the yearly release, every single person I talked to love it and want us > to keep with this cycle, as well as the more frequent bugs fixes releases. One > thing we have to slightly change is to push too many new features in each of > them, but we will get there. I'm not sure how many people you've spoken to and what their profile is, but reality shows a very different picture: 481004 PHP/5.2.17 280342 PHP/5.3.8 271156 PHP/5.2.6-1+lenny16 146342 PHP/5.2.9 133818 PHP/5.2.6 125550 PHP/5.3.10 109513 PHP/5.2.6-1+lenny13 106320 PHP/5.2.5 102412 PHP/5.2.14 81221 PHP/5.2.6-1+lenny9 These are the top-10 most popular PHP 5.x versions out there. PHP 5.4.x, in case you're wondering, shows up on the 44th place, with a bit over 20K deployments worldwide (5.4.11). With yearly release cycles, we may make the lives of a few users more enjoyable and with more rapid access to new features; But for the vast majority, we're actually making lives worse: 1. Framework & app developers can't really rely on new features anyway, since nobody has those new versions installed. Just two years ago - aiming for PHP 5.3 seemed like a bold move for ZF2 and Sf2 - and that's even though PHP 5.3 brought some revolutionary features to the mix (which 5.4 and 5.5 do not). We've also heard the Wordpress way of thinking, and we can assume that it'd take many years before other apps feel comfortable requiring a higher version than 5.3.x as a prerequisite. 2. Users who want to stay secure have to constantly upgrade, since support lifetimes have been trimmed down substantially (effectively, 3 years from release; and considering nobody upgrades on to an x.y.0 version, it's typically way less than that). We can already project that based on the current frequency, people who install PHP 5.4 today will have less than two years-worth of lifetime before they're forced to upgrade, or be left unsupported. 3. For the ecosystem in general, we're creating lots of fragmentation. All in all, I think the people who like the yearly release cycle are first and foremost bleeding edge individual developers, and not people who are a part of larger projects, or that actually have to worry about production apps working uninterrupted. Zeev --- ## #66319 — Frank Schenk — 2013-02-28T10:47:21+00:00 URL: https://externals.io/message/66277#66319 · In reply to: #66318 Hi, Am 02/28/2013 11:21 AM, schrieb Zeev Suraski: > I'm not sure how many people you've spoken to and what their profile is, > but reality shows a very different picture: > > 481004 PHP/5.2.17 > 280342 PHP/5.3.8 you can add another ~100 PHP/5.3.8 installations. For our company stability and bug fixes are way more important (like 10fold) than having fancy new features. I was asked, if we can switch to 5.4.x but i refused, because it's a couple of days work for each project to evaluate and migrate to 5.4.x > All in all, I think the people who like the yearly release cycle are first > and foremost bleeding edge individual developers, and not people who are a > part of larger projects, or that actually have to worry about production > apps working uninterrupted. I personally totally agree. Cheers, Frank -- Frank Schenk Software Analyst 2e Systems Tel: +49 - 6196 - 95058 - 30 Fax: +49 - 6196 - 95058 - 94 E-mail: frank.schenk@2e-systems.com Address: 2e Systems GmbH, Königsteiner Str. 87, D-65812 Bad Soden am Taunus Company registration: Amtsgericht Königstein (Germany), HRB 7303 Director: Philip Douglas http://www.2e-systems.com/ - making your business fly! --- ## #66320 — Lester Caine — 2013-02-28T10:54:01+00:00 URL: https://externals.io/message/66277#66320 · In reply to: #66318 Zeev Suraski wrote: > > […] > and want us > > […] > releases. One > > […] > each of > > […] > I'm not sure how many people you've spoken to and what their profile is, > but reality shows a very different picture: > > 481004 PHP/5.2.17 > 280342 PHP/5.3.8 > 271156 PHP/5.2.6-1+lenny16 > 146342 PHP/5.2.9 > 133818 PHP/5.2.6 > 125550 PHP/5.3.10 > 109513 PHP/5.2.6-1+lenny13 > 106320 PHP/5.2.5 > 102412 PHP/5.2.14 > 81221 PHP/5.2.6-1+lenny9 > > These are the top-10 most popular PHP 5.x versions out there. PHP 5.4.x, > in case you're wondering, shows up on the 44th place, with a bit over 20K > deployments worldwide (5.4.11). > With yearly release cycles, we may make the lives of a few users more > enjoyable and with more rapid access to new features; But for the vast > majority, we're actually making lives worse: > > 1. Framework & app developers can't really rely on new features anyway, > since nobody has those new versions installed. Just two years ago - > aiming for PHP 5.3 seemed like a bold move for ZF2 and Sf2 - and that's > even though PHP 5.3 brought some revolutionary features to the mix (which > 5.4 and 5.5 do not). We've also heard the Wordpress way of thinking, and > we can assume that it'd take many years before other apps feel comfortable > requiring a higher version than 5.3.x as a prerequisite. > 2. Users who want to stay secure have to constantly upgrade, since support > lifetimes have been trimmed down substantially (effectively, 3 years from > release; and considering nobody upgrades on to an x.y.0 version, it's > typically way less than that). We can already project that based on the > current frequency, people who install PHP 5.4 today will have less than > two years-worth of lifetime before they're forced to upgrade, or be left > unsupported. > 3. For the ecosystem in general, we're creating lots of fragmentation. > > All in all, I think the people who like the yearly release cycle are first > and foremost bleeding edge individual developers, and not people who are a > part of larger projects, or that actually have to worry about production > apps working uninterrupted. Finally some agreement with what I've been getting my head chewed off every time I bring it up! For the last couple of years ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #66322 — Pierre Joye — 2013-02-28T11:56:53+00:00 URL: https://externals.io/message/66277#66322 · In reply to: #66318 > I'm not sure how many people you've spoken to and what their profile is, > but reality shows a very different picture: > > 481004 PHP/5.2.17 > 280342 PHP/5.3.8 > 271156 PHP/5.2.6-1+lenny16 > 146342 PHP/5.2.9 > 133818 PHP/5.2.6 > 125550 PHP/5.3.10 > 109513 PHP/5.2.6-1+lenny13 > 106320 PHP/5.2.5 > 102412 PHP/5.2.14 > 81221 PHP/5.2.6-1+lenny9 > These are the top-10 most popular PHP 5.x versions out there. PHP 5.4.x, > in case you're wondering, shows up on the 44th place, with a bit over 20K > deployments worldwide (5.4.11). > With yearly release cycles, we may make the lives of a few users more > enjoyable and with more rapid access to new features; But for the vast > majority, we're actually making lives worse: This is amazing how you take every single opportunity to bash the new release process, forgetting all pro arguments that have been brought in the last discussions. Let me write them down again in (hopefully) a more understandable way: 1. smaller and more frequent releases are easier to manage, from a core dev, QA, ISPs and applications/developers point of view. Those are our targets, not pepsi drinkers (read: consumers, they don't even care if php runs under the hood as long as the app runs) 2. 100% BC compatibility between x.y and x.y+1. This is what prevents many ISPs and other mass hosting to update to newer PHP versions. They don't test if it works or not, they simply don't update due (too expensive in support and revert) to our past bad job on keeping BC. 3. Judging the result of this process when only one release so far has been published is totally wrong. Instead of fighting it, what's about Zend talking about it to its so numerous customers? For a change. > 1. Framework & app developers can't really rely on new features anyway, > since nobody has those new versions installed. Just two years ago - > aiming for PHP 5.3 seemed like a bold move for ZF2 and Sf2 - and that's > even though PHP 5.3 brought some revolutionary features to the mix (which > 5.4 and 5.5 do not). We've also heard the Wordpress way of thinking, and > we can assume that it'd take many years before other apps feel comfortable > requiring a higher version than 5.3.x as a prerequisite. I have discussed with many WP devs (and the lead), they all agree that this process is a good thing and will help WP to move forward. It does not mean they will stop to support older versions but they will change the recommended versions. > 2. Users who want to stay secure have to constantly upgrade, since support > lifetimes have been trimmed down substantially (effectively, 3 years from > release; and considering nobody upgrades on to an x.y.0 version, it's > typically way less than that). We can already project that based on the > current frequency, people who install PHP 5.4 today will have less than > two years-worth of lifetime before they're forced to upgrade, or be left > unsupported. Again, 1st release done via through this process. Our users (not the consumers of our users products) have to see that we keep our word, about BC, quality etc. > 3. For the ecosystem in general, we're creating lots of fragmentation. No, we do not. 5.4 code runs under 5.5 smoothly. But we do not prevent newer versions of applications or modules to rely on 5.5 features. I am convinced that the update path will be faster in the next couple of years. The only missing part now is the communication about it. I have been communicating about it at all conferences I attended as speaker (talks, keynotes, etc.). I did not see any single negative comments about it, but only positive and very motivated feedback. While people also said that they will wait to see if we keep our words (as I said earlier). > All in all, I think the people who like the yearly release cycle are first > and foremost bleeding edge individual developers, and not people who are a > part of larger projects, or that actually have to worry about production > apps working uninterrupted. Having the pros of both sides is exactly why this process has been created. Having a release active for almost a decade is simply not possible. Let me say it again, stop arguing and begin to promote and explain it to your customers. That will be much more helpful than trying to fight it with all possible ways. Thanks. Cheers, -- Pierre @pierrejoye --- ## #66323 — Zeev Suraski — 2013-02-28T13:06:07+00:00 URL: https://externals.io/message/66277#66323 · In reply to: #66322 > This is amazing how you take every single opportunity to bash the new release > process, forgetting all pro arguments that have been brought in the last > discussions. I'm not bashing it. I think the process is good. I'm saying the frequency is wrong and doesn't suit the needs of most of our users. > Let me write them down again in (hopefully) a more understandable way: You didn't state anything I wasn't aware of before, and yet, I still think that a yearly release cycle is roughly 2x too frequent from where we should be. Most users don't upgrade because they don't need the new features and can't be bothered to upgrade. There's no such thing as 100% downwards compatibility, and 5.5 will be no different in that sense from previous versions. Perhaps it'll be three nines instead of two nines (99.9% vs. 99%), but every keyword, every bug fix, every change in an error reporting level - can break apps and make an upgrade process non smooth. We're not going to be able to change people's perception. Frequent releases are less easy to manage from just about any point. Their one and only advantage is delivering features to the userbase more quickly, which begs the question whether they're eagerly waiting for such features. In terms of upgrades - you have to spend more time upgrading & testing. In terms of off-the-shelf-apps - you need to invest more in testing more versions. In terms of QA - fewer releases means less time spent in testing. > Instead of fighting it, what's about Zend talking about it to its so numerous > customers? For a change. Zend has nothing to do with it. We can't wave a magic wand and change people's perception, habits or preferences. Both our customers and the companies I get to meet don't view a yearly release cycle favorably (most of them - some do). > I have discussed with many WP devs (and the lead), they all agree that this > process is a good thing and will help WP to move forward. It does not mean they > will stop to support older versions but they will change the recommended > versions. Process != frequency. Our process is good, our frequency isn't. > No, we do not. 5.4 code runs under 5.5 smoothly. 5.3 code runs smoothly on 5.4 too (except for ancient code using features that have been deprecated for many many years). Incompats have been blown out of proportion - in the same way I can assure you the few incompats between 5.4 and 5.5 will be blown out of proportion. > Let me say it again, stop arguing and begin to promote and explain it to your > customers. I admire your self-confidence, you seem to have enough of it for a whole battalion of developers, but it's complete unwarranted in this case (as well as other cases in recent weeks). I think you're promoting a bad thing for PHP, not because our users are idiots or fail to understand the amazing advantages of a yearly release cycle - but because it's just bad. Zeev --- ## #66324 — Pierre Joye — 2013-02-28T13:11:55+00:00 URL: https://externals.io/message/66277#66324 · In reply to: #66323 hi Zeev, > Most users don't upgrade because they don't need the new features and > can't be bothered to upgrade. > > There's no such thing as 100% downwards compatibility, and 5.5 will be no > different in that sense from previous versions. Perhaps it'll be three > nines instead of two nines (99.9% vs. 99%), but every keyword, every bug > fix, every change in an error reporting level - can break apps and make an > upgrade process non smooth. We're not going to be able to change people's > perception. nitpicking. You know what I mean. > I admire your self-confidence, you seem to have enough of it for a whole > battalion of developers, but it's complete unwarranted in this case I have to suggest to join me in the next conferences then. Like the one I gave talks about this topic (DrupalCons, general PHP conferences, dozen of UGs, companies conferences, etc.). And the attendees are not the usual suspects you could find at some major US conferences. > (as well as other cases in recent weeks). I suppose you refer to my comments about us being out of sync with our user bases, let say you talk to part of our users and I do to another. Amazingly most of the frameworks and apps lead developers think the same have the same opinion, go figure. > I think you're promoting a bad > thing for PHP, not because our users are idiots or fail to understand the > amazing advantages of a yearly release cycle - but because it's just bad. I promote what I and the users I talk to believe to be a good thing. Cheers, -- Pierre @pierrejoye --- ## #66325 — Ilia Alshanetsky — 2013-02-28T13:54:26+00:00 URL: https://externals.io/message/66277#66325 · In reply to: #66318 Zeev has an excellent point here, my own research shows that 5.4, a year after release had somewhere in the 2% adoption rate. The major reason being is the lack of a stable, production ready op-code cache. To release 5.5 without a good solution for that problem, would not make the situation better, if anything it would make it very intimidating to users to jump 2-3 versions directly to 5.6. Thus leaving us with a massive user base running legacy, unsupported versions containing unresolved bugs and vulnerabilities. Something, which I don't think would be a very good thing for the future of PHP. Ultimately, I think it is better to wait a month or two (if that is what it takes) and have a solid release people can safely upgrade their production environments to, rather than strictly adhere to a set release cycle and delivery a partial solution. > > […] > and want us > > […] > releases. One > > […] > each of > > […] > > I'm not sure how many people you've spoken to and what their profile is, > but reality shows a very different picture: > > 481004 PHP/5.2.17 > 280342 PHP/5.3.8 > 271156 PHP/5.2.6-1+lenny16 > 146342 PHP/5.2.9 > 133818 PHP/5.2.6 > 125550 PHP/5.3.10 > 109513 PHP/5.2.6-1+lenny13 > 106320 PHP/5.2.5 > 102412 PHP/5.2.14 > 81221 PHP/5.2.6-1+lenny9 > > These are the top-10 most popular PHP 5.x versions out there. PHP 5.4.x, > in case you're wondering, shows up on the 44th place, with a bit over 20K > deployments worldwide (5.4.11). > With yearly release cycles, we may make the lives of a few users more > enjoyable and with more rapid access to new features; But for the vast > majority, we're actually making lives worse: > > 1. Framework & app developers can't really rely on new features anyway, > since nobody has those new versions installed. Just two years ago - > aiming for PHP 5.3 seemed like a bold move for ZF2 and Sf2 - and that's > even though PHP 5.3 brought some revolutionary features to the mix (which > 5.4 and 5.5 do not). We've also heard the Wordpress way of thinking, and > we can assume that it'd take many years before other apps feel comfortable > requiring a higher version than 5.3.x as a prerequisite. > 2. Users who want to stay secure have to constantly upgrade, since support > lifetimes have been trimmed down substantially (effectively, 3 years from > release; and considering nobody upgrades on to an x.y.0 version, it's > typically way less than that). We can already project that based on the > current frequency, people who install PHP 5.4 today will have less than > two years-worth of lifetime before they're forced to upgrade, or be left > unsupported. > 3. For the ecosystem in general, we're creating lots of fragmentation. > > All in all, I think the people who like the yearly release cycle are first > and foremost bleeding edge individual developers, and not people who are a > part of larger projects, or that actually have to worry about production > apps working uninterrupted. > > Zeev --- ## #66327 — Anthony Ferrara — 2013-02-28T14:01:30+00:00 URL: https://externals.io/message/66277#66327 · In reply to: #66325 Ilia, > Zeev has an excellent point here, my own research shows that 5.4, a > year after release had somewhere in the 2% adoption rate. The major > reason being is the lack of a stable, production ready op-code cache. > To release 5.5 without a good solution for that problem, would not > make the situation better, if anything it would make it very > intimidating to users to jump 2-3 versions directly to 5.6. Thus > leaving us with a massive user base running legacy, unsupported > versions containing unresolved bugs and vulnerabilities. Something, > which I don't think would be a very good thing for the future of PHP. > To be fair, the 5.5 situation without pulling in ZO+ is NOT the same as 5.4 was. Today, right now, there exists at least one stable open source opcode cache. 5.4 had none for many months after release. So I'm not sure if the same pressures exist. The discussion now is if we delay 5.5 to spend the time pulling it in core. But either way (in core or not), ZO+ is open and working on 5.5 alpha. So we could skip the core import, and just ship it today as gold, and it would be adoptable straight away (unlike how 5.4 was). > Ultimately, I think it is better to wait a month or two (if that is > what it takes) and have a solid release people can safely upgrade > their production environments to, rather than strictly adhere to a set > release cycle and delivery a partial solution. That's the thing though, it wouldn't be a partial solution. It would be exactly where 5.2, 5.3 and 5.4 are today, with the addition of several highly wanted features. I'd rather delay 5.6, and do a deeper integration into the engine. Then at least there's something to gain by pulling it into core, rather than just having it be a compile-time-flag as opposed to a pecl installation (which doesn't buy us *that* much)... My standpoint at least... Anthony --- ## #66328 — Jordi Boggiano — 2013-02-28T14:33:06+00:00 URL: https://externals.io/message/66277#66328 · In reply to: #66319 > For our company stability and bug fixes are way more important (like > 10fold) than having fancy new features. I was asked, if we can switch to > 5.4.x but i refused, because it's a couple of days work for each project > to evaluate and migrate to 5.4.x I can see your point, but don't you think this is also an "old" mentality that might need to be adjusted? What I mean is that with the higher frequency of releases, and the more strict "no-BC breaks" guidelines (many thanks to Pierre and others for doing your best to enforce that btw..), upgrading becomes less dangerous since there are less minor changes. I personally can't remember having any issues with 5.4 except for 5.4.0 breaking some odd things in file_get_contents, but .0 releases are always too buggy to upgrade. I have also been developing with 5.5 for a while now and did not notice anything out of the ordinary. Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi --- Next page: https://externals.io/message/66277.md?page=2