# Thresholds of backwards compatibility breaks - Thread: https://externals.io/message/78744 - Original archive: https://news-web.php.net/php.internals/78744 - Started by Florian Margaine on 2014-11-05T20:20:14+00:00 - Messages: 20 - 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 --- ## #78744 — Florian Margaine — 2014-11-05T20:20:14+00:00 URL: https://externals.io/message/78744#78744 Hi list, I'd like to introduce thresholds of backwards compatibility breaks, i.e. maximum numbers of allowed BC breaks per version. Lester's mail from a couple days ago had me thinking about the BC breaks that occur now and then in all the RFCs or all the mails I see these days. Now, take what I say with a grain of salt, as I've only recently been involved in this mailing list, as well as in php-src development. Let me explain my reasoning. To allow the users of PHP to upgrade their versions, and enjoy the new features, as well as the security fixes, the least number of BC breaks should get in the new released versions. That is because a BC break can lead to many hours of a codebase adaptation, hours that many companies don't want to pay for if the benefits are minimal. However, to allow us to evolve the language, BC breaks are a necessary evil. Another issue is the short timeline of security fixes for the versions. PHP 5.4 will have a total lifetime of 3 years, a very short one for many people. I'm not advising to increase this timeline, just saying that it gets in the equation of my discussion. To mitigate the issue of BC breaks, I think introducing the concept of thresholds would greatly help the PHP adoption, and mostly upgrades of PHP versions. If people know that a limited amount of work is going to be needed when upgrading a PHP version, the upgrades should be done more often. For example, the following thresholds could be used: - major BC break: major versions only. 5 major BC breaks allowed per major version. - minor BC break: - minor versions: 5 minor BC breaks allowed. - patch versions: 1 BC break allowed. Thoughts? Am I thinking too much? Is this idea unfeasible? Is it a good idea? Regards, -- Florian Margaine --- ## #78745 — Ferenc Kovacs — 2014-11-05T20:34:19+00:00 URL: https://externals.io/message/78744#78745 · In reply to: #78744 2014.11.05. 21:21 ezt írta ("Florian Margaine" ): > > Hi list, > > I'd like to introduce thresholds of backwards compatibility breaks, i.e. > maximum numbers of allowed BC breaks per version. > > Lester's mail from a couple days ago had me thinking about the BC breaks > that occur now and then in all the RFCs or all the mails I see these days. > Now, take what I say with a grain of salt, as I've only recently been > involved in this mailing list, as well as in php-src development. > > Let me explain my reasoning. > > To allow the users of PHP to upgrade their versions, and enjoy the new > features, as well as the security fixes, the least number of BC breaks > should get in the new released versions. That is because a BC break can > lead to many hours of a codebase adaptation, hours that many companies > don't want to pay for if the benefits are minimal. > > However, to allow us to evolve the language, BC breaks are a necessary evil. > > Another issue is the short timeline of security fixes for the versions. PHP > 5.4 will have a total lifetime of 3 years, a very short one for many > people. I'm not advising to increase this timeline, just saying that it > gets in the equation of my discussion. > > To mitigate the issue of BC breaks, I think introducing the concept of > thresholds would greatly help the PHP adoption, and mostly upgrades of PHP > versions. If people know that a limited amount of work is going to be > needed when upgrading a PHP version, the upgrades should be done more often. > > For example, the following thresholds could be used: > > - major BC break: major versions only. 5 major BC breaks allowed per major > version. > - minor BC break: > - minor versions: 5 minor BC breaks allowed. > - patch versions: 1 BC break allowed. > > Thoughts? Am I thinking too much? Is this idea unfeasible? Is it a good > idea? > > Regards, > -- > Florian Margaine You did not specify what does minor/major BC breaks mean, and for micro/patch you did not specify minor/major. I guess you meant minor BC break for a micro version, otherwise make no sense (you can't have major bc break in a micro version but you can add it with the next micro). Regardless of those, I think it would be worse from the users POV than our current policy where we target no BC breaks in minor/micro versions. The only exception should be security concerns (see the unserialize changes in 5.6 for such an example), which shows that usually BC breaks are more about the tradeoff, having a BC for a cornercase which probably nobody will notice but it will simplify the langspec/parser is a different kind of BC that switching the needle/haystack argument order or removing the dollar sign would cause. Trying to compare or quantify those are hard, and they should be decided on their own merrit not how much open slot do we have. Just my 2 cents ofc. --- ## #78765 — Pierre Joye — 2014-11-06T01:38:41+00:00 URL: https://externals.io/message/78744#78765 · In reply to: #78744 Hi, > Thoughts? Am I thinking too much? Is this idea unfeasible? Is it a good > idea? Have you missed: https://wiki.php.net/rfc/releaseprocess ? Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #78767 — Andrea Faulds — 2014-11-06T01:46:45+00:00 URL: https://externals.io/message/78744#78767 · In reply to: #78745 > > > Regardless of those, I think it would be worse from the users POV than our > current policy where we target no BC breaks in minor/micro versions. > The only exception should be security concerns (see the unserialize changes > in 5.6 for such an example), which shows that usually BC breaks are more > about the tradeoff, having a BC for a cornercase which probably nobody will > notice but it will simplify the langspec/parser is a different kind of BC > that switching the needle/haystack argument order or removing the dollar > sign would cause. > Trying to compare or quantify those are hard, and they should be decided on > their own merrit not how much open slot do we have. > > Just my 2 cents ofc. Hmm. Wouldn’t allowing minor BC breaks in minor versions be better than having BC breaks only in majors? Is it not easier to make one or two small code changes each year, than to do a massive migration every 5 years? -- Andrea Faulds http://ajf.me/ --- ## #78768 — Pierre Joye — 2014-11-06T02:00:51+00:00 URL: https://externals.io/message/78744#78768 · In reply to: #78767 > > > > […] our > > […] changes > > […] will > > […] BC > > […] decided on > > […] > > Hmm. Wouldn’t allowing minor BC breaks in minor versions be better than having BC breaks only in majors? Is it not easier to make one or two small code changes each year, than to do a massive migration every 5 years? > > -- We have minor BC breaks (new errors. Slight behavior changes due to bug fixes). But globally no, it makes end users work harder for migration, even worst for distros. See Debian f.e., they boost the adoption speed now, we finally see some results, within the 2-4 years plan we had back then. I could not imagine a worst time to rollback what we defined. --- ## #78772 — Andrea Faulds — 2014-11-06T02:27:07+00:00 URL: https://externals.io/message/78744#78772 · In reply to: #78768 > > > We have minor BC breaks (new errors. Slight behavior changes due to bug fixes). > > But globally no, it makes end users work harder for migration, even worst for distros. > > See Debian f.e., they boost the adoption speed now, we finally see some results, within the 2-4 years plan we had back then. I could not imagine a worst time to rollback what we defined. > Ah, you raise a good point there. It’d be a shame if distros stopped shipping new minor versions of PHP. Alright then. Perhaps, instead, the solution is more frequent majors, with less BC breaks each. -- Andrea Faulds http://ajf.me/ --- ## #78785 — Ferenc Kovacs — 2014-11-06T06:49:57+00:00 URL: https://externals.io/message/78744#78785 · In reply to: #78767 2014.11.06. 2:46 ezt írta ("Andrea Faulds" ): > > > > […] our > > […] changes > > […] will > > […] BC > > […] decided on > > […] > > Hmm. Wouldn’t allowing minor BC breaks in minor versions be better than having BC breaks only in majors? Is it not easier to make one or two small code changes each year, than to do a massive migration every 5 years? With major versions you have years to migrate(while we don't cover this in our release process rfc, but we tend to keep the previous major version alive for years) but I do agree that more frequent but smaller BC breaks are better, but I would use that as an argument for having smaller but more frequent majors. Like a new major version every 3 years where we provide support 2years standard and 1 year security support, so we always have 2 major branches active, but never have more than two minor versions for a major. But this probably needs a bit more thought. --- ## #78790 — Lester Caine — 2014-11-06T07:43:55+00:00 URL: https://externals.io/message/78744#78790 · In reply to: #78772 > > […] > Ah, you raise a good point there. It’d be a shame if distros stopped shipping new minor versions of PHP. > > Alright then. Perhaps, instead, the solution is more frequent majors, with less BC breaks each. Hindsight is a wonderful thing ... While yes one can run PHP5.2 code on PHP5.4 by hiding everything that PHP5.4 does not like, in the real world trying to run the two side by side simply does not work. PHP5.4 was essentially a major version - if you assume that e_strict failures have to be fixed. IF 5.4 had been released as PHPNext then those of us who have to live with the fallout COULD have managed legacy code with PHP5.3. Yes it is only a number, but a lot more problematic changes WERE pushed through across those three versions which would have been much safer handled by removing e_strict from PHP5.4 rather than trying to live with both versions of PHP. -- 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 --- ## #78792 — Kris Craig — 2014-11-06T07:53:58+00:00 URL: https://externals.io/message/78744#78792 · In reply to: #78785 > 2014.11.06. 2:46 ezt írta ("Andrea Faulds" ): > > […] > our > > […] > changes > > […] > more > > […] > will > > […] > BC > > […] > dollar > > […] > decided on > > […] > having BC breaks only in majors? Is it not easier to make one or two small > code changes each year, than to do a massive migration every 5 years? > > With major versions you have years to migrate(while we don't cover this in > our release process rfc, but we tend to keep the previous major version > alive for years) but I do agree that more frequent but smaller BC breaks > are better, but I would use that as an argument for having smaller but more > frequent majors. Like a new major version every 3 years where we provide > support 2years standard and 1 year security support, so we always have 2 > major branches active, but never have more than two minor versions for a > major. > But this probably needs a bit more thought. > It's more than just a matter of time and convenience, though. It also has to do with expectations. There is a predominant expectation that upgrading minor increments on the same major release branch is essentially safe; that you won't have to worry about BC breaks-- minor or otherwise-- causing your code to start failing. Furthermore, as someone else already pointed out, "major" and "minor" can be very subjective terms and would likely lead to increased confusion. Many maintainers would probably opt not to just stay on their current version rather than risk a BC break that someone here regarded as "minor" causing their code to blow-up. This is especially problematic given that essential security updates and bug fixes are frequently included in minor version releases. It could be argued that staying current with the latest minor increment on whatever major branch you're on is more important than being on the latest major increment for that very reason. I fear that this proposal would undermine that and erode the trust people currently have in our minor releases to be BC-friendly, drastically curtailing the proliferation of critical bug fixes and security updates. Historically, we haven't had much trouble on that side of the coin and I'd prefer to keep it that way. On the flip side, of course, there is also an expectation that major increments will have BC breaks and will likely require updates to your code; which, in turn, leads to the expectation that adoption of new major version releases will be gradual. I've often argued here that we tend to allow known flaws to persist in major version increments due to an inappropriate level of concern for BC in major release increments and I still believe that. That said, this proposal would represent the opposite extreme, making our minor releases too unreliable in terms of BC for many people's comfort. Also, the limit of 5 BC breaks seems completely arbitrary. Why not 6? Or 4? There's no rational basis for that number that I can see and it could potentially tie our hands when faced with a major revision of some kind that would carry more BC breaks with it. I do like the idea of having a clear, consistent policy regarding BC and version increments. I just don't think the specifics of the proposal are the right way to go about doing that. --Kris --- ## #78805 — Christoph Becker — 2014-11-06T11:16:42+00:00 URL: https://externals.io/message/78744#78805 · In reply to: #78790 Lester Caine wrote: > Yes it is only a number, but a lot more problematic changes WERE pushed > through across those three versions which would have been much safer > handled by removing e_strict from PHP5.4 rather than trying to live with > both versions of PHP. I don't see a problem with regard to E_STRICT. If your code is not yet strict compliant, simply turn it off for error_reporting: error_reporting = `E_ALL` & ~E_STRICT -- Christoph M. Becker --- ## #78812 — Ferenc Kovacs — 2014-11-06T12:10:26+00:00 URL: https://externals.io/message/78744#78812 · In reply to: #78805 > Lester Caine wrote: > > > […] > > I don't see a problem with regard to E_STRICT. If your code is not yet > strict compliant, simply turn it off for error_reporting: > > error_reporting = `E_ALL` & ~E_STRICT > > -- > Christoph M. Becker > > -- > > > > for the record, see https://bugs.php.net/bug.php?id=65322 and the issued linked from that. turned out that we had a bug, which prevented the autoload calls inside an error handler call when the original error was a compile time one. we have some compile time strict errors about abstract classes which could have triggered hard-to-debug fatal errors for people(with custom error handlers which depend on dynamic auto loading) when we made `E_STRICT` part of `E_ALL` in 5.4. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #78813 — Lester Caine — 2014-11-06T12:16:43+00:00 URL: https://externals.io/message/78744#78813 · In reply to: #78805 > > […] > I don't see a problem with regard to E_STRICT. If your code is not yet > strict compliant, simply turn it off for error_reporting: > > error_reporting = `E_ALL` & ~E_STRICT I get tired say this !!! The problem is trying to maintain TWO totally incompatible code bases side by side. It is all to easy to have a wrong setting, or pick up a 'e_strict' version library with a not yet fixed set of code! If many of the libraries I work with had NOT been updated there would be less of a problem, but the ONLY way to prevent white screen sites is to get rid of all of the old code ... which is still unfortunately work in progress ... Keeping the non e-strict code on a PHP5.2 powered server and only using e_strict compliant on the PHP5.4, we maintain stable operation, but ISP's are upgrading shared hosting and that is where ring fencing the legacy code is time consuming and detracting from getting code cleaned up. And switching off error reporting only adds to the problems recovering sites which have gone down. I know people seem to think that this is not acceptable on production sites, but my code had always run clean and a visible error can be picked up and fixed while checking through a large number of log files across many services to see if there are problems is not something I want to spend my days doing! Screwing up the code and then hiding the results is NOT maintaining BC! -- 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 --- ## #78815 — Christoph Becker — 2014-11-06T13:32:33+00:00 URL: https://externals.io/message/78744#78815 · In reply to: #78812 Ferenc Kovacs wrote: > > > > […] > > for the record, see https://bugs.php.net/bug.php?id=65322 and the issued > linked from that. > turned out that we had a bug, which prevented the autoload calls inside an > error handler call when the original error was a compile time one. > we have some compile time strict errors about abstract classes which could > have triggered hard-to-debug fatal errors for people(with custom error > handlers which depend on dynamic auto loading) when we made `E_STRICT` part > of `E_ALL` in 5.4. Thanks for pointing this out -- I have not been aware of the issue. Of course, having had this bug for such a long time is unfortunate, but it seems to me a viable userland workaround for not yet "strict" code to support affected PHP versions would be to pass an appropriate $error_types argument to the set_error_handler call, e.g. set_error_handler('my_error_handler', `E_ALL` & ~E_STRICT); -- Christoph M. Becker --- ## #78818 — Ferenc Kovacs — 2014-11-06T14:22:36+00:00 URL: https://externals.io/message/78744#78818 · In reply to: #78815 > Ferenc Kovacs wrote: > > > […] > wrote: > > […] > with > > […] > an > > […] > could > > […] > > Thanks for pointing this out -- I have not been aware of the issue. Of > course, having had this bug for such a long time is unfortunate, but it > seems to me a viable userland workaround for not yet "strict" code to > support affected PHP versions would be to pass an appropriate > $error_types argument to the set_error_handler call, e.g. > > set_error_handler('my_error_handler', `E_ALL` & ~E_STRICT); > > -- > Christoph M. Becker > > the bug is already fixed by Nikita, I only brought it up, as an example that migrating to 5.4 and the fact that we included `E_STRICT` to `E_ALL` could indeed cause fatal errors for some application. ofc after you realize the issue, there were a couple of ways to mitigate it (the easiest is to change your php.ini to remove `E_STRICT` from error_reporting or changing your error handler to not care about these kind of errors or to not depend on the availability of your autoloader). -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #78829 — Stas Malyshev — 2014-11-07T00:43:48+00:00 URL: https://externals.io/message/78744#78829 · In reply to: #78744 Hi! > - major BC break: major versions only. 5 major BC breaks allowed per major > version. I'm not sure how such numbers make sense. Why 5 and not 3 or 7 or 17? If that breaks your code, even one is too much. If your code is not affected, why would you care if it's 5 or 15 or 150? I'm afraid this would just devolve into semantics discussion and arguments about how to count them and why it can be 5 but not 6. I don't see any reason to put any numeric value on it. > - minor BC break: > - minor versions: 5 minor BC breaks allowed. > - patch versions: 1 BC break allowed. Patch & minors should not have BC breaks, excepting bugfixes where it is inevitable. Of course, it is an ideal situation, and in practice we may miss stuff, or we may not have a choice, or we may prefer BC break to the alternative. But again I don't see how putting a number on it helps something. If we have two cases where we must have BC break and not one - and we absolutely sure we have no better choice and that's what we have to do - how having arbitrary limit of 1 would help? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ --- ## #78834 — Christoph Becker — 2014-11-07T01:59:33+00:00 URL: https://externals.io/message/78744#78834 · In reply to: #78813 Lester Caine wrote: > > > […] > > I get tired say this !!! > > The problem is trying to maintain TWO totally incompatible code bases > side by side. It is all to easy to have a wrong setting, or pick up a > 'e_strict' version library with a not yet fixed set of code! > If many of the libraries I work with had NOT been updated there would be > less of a problem, but the ONLY way to prevent white screen sites is to > get rid of all of the old code ... which is still unfortunately work in > progress ... Well, that's life. If you have a car that needs leaded fuel, you might have a hard time to drive it nowadays. > Keeping the non e-strict code on a PHP5.2 powered server and only using > e_strict compliant on the PHP5.4, we maintain stable operation, but > ISP's are upgrading shared hosting and that is where ring fencing the > legacy code is time consuming and detracting from getting code cleaned up. Actually, you shouldn't have to have "strict" compliant code for PHP 5.4. Ferenc pointed out a particular bug, where "non strict" code would throw a fatal error, but this has been fixed, and there are several general workarounds.[1] If there are other bugs in this regard, you ought to report these. > And switching off error reporting only adds to the problems recovering > sites which have gone down. I know people seem to think that this is not > acceptable on production sites, but my code had always run clean and a > visible error can be picked up and fixed while checking through a large > number of log files across many services to see if there are problems is > not something I want to spend my days doing! Nobody suggested to switch off error reporting. IMO, `E_STRICT` is supposed to be a weak form of E_DEPRECATED, i.e. a hint for the developer to modernize the code in the near future. Until this can be done, it seems to be perfectly fine to suppress *these* warnings. When the developer finds the time to fix the outstanding issues, running the test suite in a development environment should catch most (if not all) of them. If there is no test suite, the developer is likely to be out of luck anyway, IMHO. > Screwing up the code and then hiding the results is NOT maintaining BC! Apparently, the inclusion of `E_STRICT` to `E_ALL` wasn't supposed to screw up anything. [1] -- Christoph M. Becker --- ## #78857 — Lester Caine — 2014-11-09T20:48:25+00:00 URL: https://externals.io/message/78744#78857 · In reply to: #78834 > Nobody suggested to switch off error reporting. IMO, `E_STRICT` is > supposed to be a weak form of E_DEPRECATED, i.e. a hint for the > developer to modernize the code in the near future. Until this can be > done, it seems to be perfectly fine to suppress *these* warnings. When > the developer finds the time to fix the outstanding issues, running the > test suite in a development environment should catch most (if not all) > of them. If there is no test suite, the developer is likely to be out > of luck anyway, IMHO. > > > […] > Apparently, the inclusion of `E_STRICT` to `E_ALL` wasn't supposed to screw > up anything. Incremental changes from one version to the next may work for some people. The problem is bringing Pre-5.2 code forward so that it can reliably co-exist with already 'fixed' code. Many of the ISP's who tried simply switching their shared hosting to 5.4 found that so many sites simply stopped working that they had to revert the change. It is not 'developers' who have to find the time to make legacy code work on current servers ... it's users who have no idea even where to start! That their site is simply producing a white screen is not a help so perhaps the 'defaults' would be better off in favour of the unsophisticated user rather than something that pleases developers? Not that it helps anyway since distributions all throw their own two pennies in, and the 'suggested fixes' fail because the files are not where we tell them. That is if the hosting company even allow access. -- 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 --- ## #78858 — Rowan Collins — 2014-11-09T21:59:24+00:00 URL: https://externals.io/message/78744#78858 · In reply to: #78857 > > > […] > Incremental changes from one version to the next may work for some > people. The problem is bringing Pre-5.2 code forward so that it can > reliably co-exist with already 'fixed' code. Many of the ISP's who tried > simply switching their shared hosting to 5.4 found that so many sites > simply stopped working that they had to revert the change. It is not > 'developers' who have to find the time to make legacy code work on > current servers ... it's users who have no idea even where to start! > That their site is simply producing a white screen is not a help so > perhaps the 'defaults' would be better off in favour of the > unsophisticated user rather than something that pleases developers? Not > that it helps anyway since distributions all throw their own two pennies > in, and the 'suggested fixes' fail because the files are not where we > tell them. That is if the hosting company even allow access. > Well, in the scenario you just described, it is the service provider who is choosing a) the version of PHP, and b) the default configuration for users on their system. If somebody is running shared hosting and can't correctly work with an ini file, and read the release notes from php.net, they're probably in the wrong business. The users - if they're not developers - are presumably installing specific pieces of software created by known 3rd-parties; often, they are doing so using control panel tools provided by the hosting provider. The hosting providers have to work with the users to find out if the software in use will work on a particular platform; but that's a case of asking the developers and getting an answer "yes" or "no" (or "soon"). A stronger compatibility between releases makes it easier for the developers to say "yes", but if there is no developer willing to fix it, even a single incompatible line (which is an inevitable risk if the language doesn't completely stagnate) is too much. (If you're willing to hack the code to make it work, you are, at that point, volunteering as a developer not a user.) None of which has anything to do with E_STRICT. Strict notices aren't indications that behaviour has changed; since we have E_DEPRECATED, they shouldn't even indicate behaviour is about to change; they just indicate that there might be a better way of doing what you're doing. I don't know why you consider them to be in the same category as code compatibility at all. -- Rowan Collins [IMSoP] --- ## #78860 — Lester Caine — 2014-11-09T22:39:09+00:00 URL: https://externals.io/message/78744#78860 · In reply to: #78858 > None of which has anything to do with E_STRICT. Strict notices aren't > indications that behaviour has changed; since we have E_DEPRECATED, they > shouldn't even indicate behaviour is about to change; they just indicate > that there might be a better way of doing what you're doing. I don't > know why you consider them to be in the same category as code > compatibility at all. That the traditional method of using PHP5 is no longer politically correct is the problem here. One can not use both methods of working at the same time, and since in many cases the third party libraries HAVE been upgraded and require a later version of PHP even to run, HELPING users who had perfectly functional sites based on code that was created using what are still current tutorials but which no longer produce acceptable code is the main problem here. To pretend that PHP5.4 and later can safely run legacy code is the problem, and these are BC breaks that people are pretending have not happened simply because they assume they can be ignored. One method of working may be to configure a PHP setup which blocks any use of e_strict compliant rules and make sure only legacy compatible code is running. Then legacy sites can be kept running without the effort of converting the code to clean e_strict compliance. The main question that should probably be asked is if PHP7 will maintain this source of confusion or ONLY allow e_strict compliance? Certainly I'd prefer to see this on plugged. It is all to easy to have some upgrade override your settings and introduce random breaks in things. THAT is still a major source of agro, with third party libraries overriding settings after one has ensured there were set correctly. It's not SIMPLY ensuring that the hosting is set up correctly, it's the fact that any library can screw that up! -- 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 --- ## #78861 — Rowan Collins — 2014-11-10T09:55:05+00:00 URL: https://externals.io/message/78744#78861 · In reply to: #78860 Lester Caine wrote on 09/11/2014 22:39: > > > […] > That the traditional method of using PHP5 is no longer politically > correct is the problem here. One can not use both methods of working at > the same time, and since in many cases the third party libraries HAVE > been upgraded and require a later version of PHP even to run, HELPING > users who had perfectly functional sites based on code that was created > using what are still current tutorials but which no longer produce > acceptable code is the main problem here. To pretend that PHP5.4 and > later can safely run legacy code is the problem, and these are BC breaks > that people are pretending have not happened simply because they assume > they can be ignored. Yes, many pieces of software have a minimum PHP version to run, often because they make use of useful new features, e.g. namespaces and closures from PHP 5.3. This is a very different kind of compatibility from old software not working on newer versions of PHP; it is up to the projects in question to decide which versions to support. > One method of working may be to configure a PHP setup which blocks any > use of e_strict compliant rules and make sure only legacy compatible > code is running. Then legacy sites can be kept running without the > effort of converting the code to clean e_strict compliance. The main > question that should probably be asked is if PHP7 will maintain this > source of confusion or ONLY allow e_strict compliance? Certainly I'd > prefer to see this on plugged. It is all to easy to have some upgrade > override your settings and introduce random breaks in things. THAT is > still a major source of agro, with third party libraries overriding > settings after one has ensured there were set correctly. It's not SIMPLY > ensuring that the hosting is set up correctly, it's the fact that any > library can screw that up! There should be no problem with fixing some strict notices and not others, so I don't understand your comment on blocking e_strict compliance in order to run legacy code. Can you give an example of a notice where you would want to actually *prevent compliance*, rather than just ignoring the notice if you don't have time to fix it? Again, updating code may well raise the minimum required PHP version, but this is much more likely to be because the developer wants to take advantage of new features, not because they're trying to run with no strict notices. -- *Rowan Collins* *Senior Developer | CWT Digital* *t.* 0845 456 0070 *w.*cwtdigital.com