Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Sent from my iPhone On 5 Feb, 2013, at 9:20 PM, Martin Keckeis martin.kecke...@gmail.com wrote: http://w3techs.com/**technologies/history_details/**pl-php/5http://w3techs.com/technologies/history_details/pl-php/5use of PHP5.1 is slowing faster than 5.4 use is growing. This is wrong. At May 2012: PHP 5.1 starts with 4.9% PHP 5.4 start with 0.1 % In Februar 2013: PHP 5.1 has now 3.2% = lose of 1.7% PHP 5.4 has now 2.2% = grow of 2.1% One does not simply apply growth calculations by mere subtractions. PHP 5.1 shrank by 34% PHP 5.4 grew by 2100% :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 05/02/13 21:16, Karoly Negyesi wrote: new keywords is an interesting discussion to have -- it's actually the first real thing to discuss as far as I can see. For example that is something that version strings would tremendously help. You do not need to maintain the whole lot of behaviors for every version just the parser? Also, new keywords typically introduce new syntax. Here's an example, a quick github code search found https://github.com/chriso/klein.php/blob/master/klein.php#L600 this. function yield() is not a valid usage of the new yield keyword nor is yield() so perhaps it's not impossible to accomodate this kind of code? Let's discuss. That's one of the easiest incompatibilities to detect (run new-php -l to all your files), and also to fix (replace all instances of that new keyword with a new name). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
I don't see the problem for a software with this minor BC breaks from 5.3 to 5.5. The biggest change ever happened with namespaces and so in in 5.3 should already be done. If you have to change some parts, this is done in a few hours/days, with search and replace and a little bit handwork. And for the good feeling after refactoring, there are UnitTests around today.
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Rasmus Lerdorf wrote: It would make everyone's life so much easier if all the Drupal 8 code that is being written and tested with 5.4 would just work 5.5 without *any* problem. Yup, so please test it against 5.5 now. Have you done so? It is rather trivial to do. Grab it from git or there is a tarball athttp://qa.php.net Perhaps when I've finished the time machine ... In reality we have to make choices where we DO spend time. There is still a mile of code out there being used live which is running perfectly on the PHP5.2 infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4 before we get around to 5.5. This is perhaps the main problem with accelerating the release timetable in that there simply is not enough time to bring everybody along? So something has to give and at the moment for me it's going to have to be 5.5 ... but by the time all the legacy stuff is up to 5.4 you will be way off in the distance :( -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
hi Karoly, On Tue, Feb 5, 2013 at 7:35 AM, Karoly Negyesi kar...@negyesi.net wrote: OK, let's try this again. Maybe language versioning is out. That's sad, but this thread brought to light a much more important problem I would like to try to address. I have long felt the PHP team is living in another world I do. Sometimes yes, sometimes no. Users form a pyramid. The bottom is shared hosts. Shared hosts that we need to take into consideration. So if the shared world just barely switched to 5.3 default then, alas, we can't release a version that requires PHP 5.4 because there is no shared support for it. Also, it worths mentioning that one of the more popular server OSes, Ubuntu LTS also doesn't have a PHP 5.4 yet. Without software demanding 5.4, hosts won't upgrade. This is a vicious circle that is superb hard to break. And we changed what we used to be or used to do to ease this process. I was told in this thread that the new release process solves this and it is our and our users role to explain that to their ISPs, admins, etc. Well, what am I to explain? As I mentioned previously, if a shared host does a PHP upgrade and their users see new error messages, then the host have a support problem. Explaining new notices or warnings being non fatal or not adding BC issues are what apps/libraries developers should document, for previous versions. Fixing them in newer updates (even minor) is easy and will still work when executed on older PHP versions. It would make everyone's life so much easier if all the Drupal 8 code that is being written and tested with 5.4 would just work 5.5 without *any* problem. That's why we do test almost all commits with all major apps or frameworks. And that's why you should do it as well with your apps and report any actual BC breaks. I would absolutely love not to have this conversation again three years from now when we need to decide to ship Drupal 9 with PHP 5.5 or 5.4 -- because we could indeed do a campaign when 5.4 is due to change to 5.5 outright because it won't break BC with 5.4. Is this absolutely unattainable? What seems to be unattainable to me is this kind of discussions, you kept on your positions and refused to understand the actual need of adding notices or warnings for non supported/edge cases where the code behavior cannot be guaranteed. This is a circular discussion and I don't see how it could end. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.02.2013 09:14, schrieb Lester Caine: f code out there being used live which is running perfectly on the PHP5.2 infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4 before we get around to 5.5. This is perhaps the main problem with accelerating the release timetable in that there simply is not enough time to bring everybody along? So something has to give and at the moment for me it's going to have to be 5.5 ... but by the time all the legacy stuff is up to 5.4 you will be way off in the distance :( Actually, it doesn't matter. Three years worth of changes are just the same, be it in one or three versions. With faster and less radical steps, there is a better chance the provider's upgrade cycle fits PHP's upgrade cycle and just misses by one or two minor changesets rather than one big. It also makes make the site work again a more regular, but easier task and increases customers' awareness that unmaintained web software will not continue to run indefinately. Just as putting your legacy DOS app onto a new computer after the 15 year old legacy system finally broke down will require some brains to make work again. As a supporter / hired external consultant I would like that. - -- Ralf Lang Linux Consultant / Developer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEQ6/UACgkQCs1dsHJ/X7Dp+QCg0prN0juyUojOuJRJ5GM1TwdS sr8An28l0a18Idsfh6kw/8xPZ8cQwrJH =65H6 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
- Ursprüngliche Message - Von: Lester Caine les...@lsces.co.uk An: internals@lists.php.net internals@lists.php.net CC: Gesendet: 9:14 Dienstag, 5.Februar 2013 Betreff: Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning Rasmus Lerdorf wrote: It would make everyone's life so much easier if all the Drupal 8 code that is being written and tested with 5.4 would just work 5.5 without *any* problem. Yup, so please test it against 5.5 now. Have you done so? It is rather trivial to do. Grab it from git or there is a tarball athttp://qa.php.net Perhaps when I've finished the time machine ... In reality we have to make choices where we DO spend time. There is still a mile of code out there being used live which is running perfectly on the PHP5.2 infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4 before we get around to 5.5. Why do you change the infrastructure if the code does not need it? I mean, provide the infrastructure the code needs and done. There is more than one vendor that offers support for PHP 5.2 infrastructure in the market. What's the deal? This is perhaps the main problem with accelerating the release timetable in that there simply is not enough time to bring everybody along? So something has to give and at the moment for me it's going to have to be 5.5 ... but by the time all the legacy stuff is up to 5.4 you will be way off in the distance :( There was no acceleration in the release timetable from my point of view. The whole show was stopped between PHP 5.2 and 5.3. This has been fixed now by explicitly having the one-year rhythm for major releases again - documented publicly for the first time in PHP history (IRC). I like the idea to know that a new major is scheduled for the first of march. The equinox, can't you feel it? Would be great to know we get PHP 5.6 shipped until the next solar eclipse. Also these yearly release period (the Rhythm) does not mean that it accelerated. It just helps you (and everybody else) with dancing, coordinating and planning. E.g. you can choose your speed by explicitly for example by leaving one major version out (skipping it) because you know when you can expect the next major release - thanks to rhythm - as well as you know how long it will be supported by the project. When we got rhythm I can call my jamaican guy while being a slave to it. Grace Jones knew that. It's all leisure, no stress. The PHP userbase just grew too large you can find a solution for everyone. Having a clear release rhythm still helps everyone and looks like an appropriate tool to me. And yeah, code, you need to refactor, always. We can't change that, nobody can. PHP might have made us lazy, which is fine, however, time goes by. Just some weeks ago I killed one of my PHP 5 babies (and it could have run even longer technically, despite the PHP releases since it saw light of day). The whole application is not needed any longer (thanks to the great improvements we have with frameworks and libraries since PHP 5.3 and 5.4). Don't work against the community, try to find good solutions of which everybody can benefit. Sure we all have issues, but the key point is to be flexible with the solutions. Be it just taking the releases of PHP 5.2 supported by third-party vendors or keeping up with the later stable leaving a time-window of three years to switch between one PHP version to the other. Additionally if even this time-frame does not work out for more than *one* version change, you can even skip up to two major versions to keep up with the rest of the gang to latest. I think it was never that easy as it is today. -- hakre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
hakre wrote: In reality we have to make choices where we DO spend time. There is still a mile of code out there being used live which is running perfectly on the PHP5.2 infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4 before we get around to 5.5. Why do you change the infrastructure if the code does not need it? I mean, provide the infrastructure the code needs and done. There is more than one vendor that offers support for PHP 5.2 infrastructure in the market. What's the deal? The point here is supporting customers that I've 'acquired' who are currently hosted on services that control that infrastructure. The long term aim is to move them to servers under our control, but in the meantime until contracts run out we have to live with such activity as 'We will be updating to PHP5.3 on the 1st April'. The problem now is how to deal with that situation, and paying up outstanding contracts may be the solution. The code needs updating, and updating to 5.4 would be useful, but short term everything needs testing and fixing for PHP5.3 :( The whole reason that ISP's are currently moving from PHP5.2 to PHP5.3 rather than PHP5.4 is that there is a better chance that their client sites will continue to work. http://w3techs.com/technologies/history_details/pl-php/5 use of PHP5.1 is slowing faster than 5.4 use is growing. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
This is a circular discussion and I don't see how it could end. I do. Let's put up an RFC for it. That is one of the reasons we established that process, isn't it? So that ideas like this don't just end up in infinite discussions that go nowhere? Karoly, are you familiar with our RFC process? If not, take a look at http://wiki.php.net/rfc. You've clearly invested a lot of thought into this, so let's go ahead and put that into an actual proposal. I'll be glad to help, including posting it to the wiki if you don't have an account. I'll be honest: I don't think it'll pass. I'd be voting no on it if that vote were held right now. But at least you'll have an actual proposal on record and you'll have at least a week (or is it two?) to try to change people's minds before it goes to a vote. I think that would be the best way to close the lid on this. If somebody brings it up again in the near future, we can simply point them to the RFC to demonstrate that the issue has already been raised and decided. Problem solved. If anybody has a better idea on how to put this discussion to rest, I'm all ears. =) --Kris
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
- Ursprüngliche Message - Von: Lester Caine les...@lsces.co.uk An: internals@lists.php.net internals@lists.php.net CC: Gesendet: 13:42 Dienstag, 5.Februar 2013 Betreff: Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning hakre wrote: In reality we have to make choices where we DO spend time. There is still a mile of code out there being used live which is running perfectly on the PHP5.2 infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4 before we get around to 5.5. Why do you change the infrastructure if the code does not need it? I mean, provide the infrastructure the code needs and done. There is more than one vendor that offers support for PHP 5.2 infrastructure in the market. What's the deal? The point here is supporting customers that I've 'acquired' who are currently hosted on services that control that infrastructure. The long term aim is to move them to servers under our control, but in the meantime until contracts run out we have to live with such activity as 'We will be updating to PHP5.3 on the 1st April'. The problem now is how to deal with that situation, and paying up outstanding contracts may be the solution. The code needs updating, and updating to 5.4 would be useful, but short term everything needs testing and fixing for PHP5.3 :( This might be starting to become slightly off-topic for the list, but what prevents you from communicating the problem to your customers and also offering them the help they need? The whole reason that ISP's are currently moving from PHP5.2 to PHP5.3 rather than PHP5.4 is that there is a better chance that their client sites will continue to work. I can not say that for the ISPs I use and I've been talking to. For the handmade ones it's more what their distro offers, for the commercially professional ones it's more what their users ask for. http://w3techs.com/technologies/history_details/pl-php/5 use of PHP5.1 is slowing faster than 5.4 use is growing. I must admit I lack of skill reading statistics, however, I don't understand why you talk about PHP 5.1 while your problem is that some contracted services of your customers is changing to PHP 5.3 from 5.2. If you need a helping hand in porting legacy 5.2 code to 5.3, feel free to contact me. -- hakre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
http://w3techs.com/**technologies/history_details/**pl-php/5http://w3techs.com/technologies/history_details/pl-php/5use of PHP5.1 is slowing faster than 5.4 use is growing. This is wrong. At May 2012: PHP 5.1 starts with 4.9% PHP 5.4 start with 0.1 % In Februar 2013: PHP 5.1 has now 3.2% = lose of 1.7% PHP 5.4 has now 2.2% = grow of 2.1%
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Martin Keckeis wrote: http://w3techs.com/__technologies/history_details/__pl-php/5 http://w3techs.com/technologies/history_details/pl-php/5 use of PHP5.1 is slowing faster than 5.4 use is growing. This is wrong. At May 2012: PHP 5.1 starts with 4.9% PHP 5.4 start with 0.1 % In Februar 2013: PHP 5.1 has now 3.2% = lose of 1.7% PHP 5.4 has now 2.2% = grow of 2.1% But PHP5.4 was released 1st March ;) So 5.6% rather than 4.9% and a loss of 2.4% I was just looking at the graph ;) Take up of 5.4 is having very little impact on the switch TO PHP5.3 is the point though. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Tue, Feb 5, 2013 at 1:42 PM, Lester Caine les...@lsces.co.uk wrote: hakre wrote: In reality we have to make choices where we DO spend time. There is still a mile of code out there being used live which is running perfectly on the PHP5.2 infrastructure. That needs testing and reworking on PHP5.3 and then PHP5.4 before we get around to 5.5. Why do you change the infrastructure if the code does not need it? I mean, provide the infrastructure the code needs and done. There is more than one vendor that offers support for PHP 5.2 infrastructure in the market. What's the deal? The point here is supporting customers that I've 'acquired' who are currently hosted on services that control that infrastructure. The long term aim is to move them to servers under our control, but in the meantime until contracts run out we have to live with such activity as 'We will be updating to PHP5.3 on the 1st April'. The problem now is how to deal with that situation, and paying up outstanding contracts may be the solution. The code needs updating, and updating to 5.4 would be useful, but short term everything needs testing and fixing for PHP5.3 :( The whole reason that ISP's are currently moving from PHP5.2 to PHP5.3 rather than PHP5.4 is that there is a better chance that their client sites will continue to work. http://w3techs.com/technologies/history_details/pl-php/5 use of PHP5.1 is slowing faster than 5.4 use is growing. If you do commercial support for customers and do not control the environment and/or use shared hosting, then something is totally wrong in your business model. It is also really off topic, in this mailing list or in this discussion. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Pierre Joye wrote: If you do commercial support for customers and do not control the environment and/or use shared hosting, then something is totally wrong in your business model. It is also really off topic, in this mailing list or in this discussion. It is totally on topic! The REASON I have gained this particular additional customer base is because they are all having problems with keeping their sites active! I had hoped to be producing a better set of documentation to help these type of users to cope with the 'BC compatibility' problems they are currently fighting, but there is nothing consistent to document. There are as many problems as customers with several years of legacy code written by different programmers :( THEY are not programmers ... I hope that as some point there will be some REAL support for stopping 'developing' PHP5 and move all of the new 'features' being discussed into a nice cleanly isolated PHP6 development stream. Then we can start documenting what IS being removed and stop trying to track which legacy feature needs to be re-worked rather than simply burying heads in sand and hiding them!!! My current roadmap is based on PHP5.4 servers with nothing hidden and eventually all of the code will be moved forward to that base, but I simply can't justify charging some customers for all the time this takes because they HAVE working sites currently and this is not giving them any return. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Tue, Feb 5, 2013 at 5:21 PM, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: If you do commercial support for customers and do not control the environment and/or use shared hosting, then something is totally wrong in your business model. It is also really off topic, in this mailing list or in this discussion. It is totally on topic! The REASON I have gained this particular additional customer base is because they are all having problems with keeping their sites active! I had hoped to be producing a better set of documentation to help these type of users to cope with the 'BC compatibility' problems they are currently fighting, but there is nothing consistent to document. There are as many problems as customers with several years of legacy code written by different programmers :( THEY are not programmers ... I hope that as some point there will be some REAL support for stopping 'developing' PHP5 and move all of the new 'features' being discussed into a nice cleanly isolated PHP6 development stream. Then we can start documenting what IS being removed and stop trying to track which legacy feature needs to be re-worked rather than simply burying heads in sand and hiding them!!! My current roadmap is based on PHP5.4 servers with nothing hidden and eventually all of the code will be moved forward to that base, but I simply can't justify charging some customers for all the time this takes because they HAVE working sites currently and this is not giving them any return. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I hope that as some point there will be some REAL support for stopping 'developing' PHP5 and move all of the new 'features' being discussed into a nice cleanly isolated PHP6 development stream. Just see it as a car: you can drive it 10 years or longer, but from time to time you need new tires or repair some stuff. Regards, Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
hi, On Tue, Feb 5, 2013 at 5:21 PM, Lester Caine les...@lsces.co.uk wrote: It is totally on topic! no, really not. :( THEY are not programmers ... But you are. Evolution of the platform as a whole is part of the support, if desired and necessary. My current roadmap is based on PHP5.4 servers with nothing hidden and eventually all of the code will be moved forward to that base, but I simply can't justify charging some customers for all the time this takes because they HAVE working sites currently and this is not giving them any return. And the working sites will still work later as well if they don't change the platform. However porting applications to supported platforms is part of a support contract, and costs should or can be described. It is even easier now that we have a fixed life cycle (three years). But again, how one should do support or define the needs of his customers so they won't be in trouble (and himself neither) is not a topic for this list. cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Am 04.02.2013 08:14, schrieb Jan Ehrhardt: Thomas Bley in php.internals (Mon, 4 Feb 2013 02:06:02 +0100): If I see it correctly, none of Debian, Ubuntu, openSUSE, CentOS, Fedora currently offer more than one version of PHP. Yes. Even SUSE Linux Enterprise Server 11 SP 2 which ships both legacy 5.2 php5 and more recent 5.3 php53 makes them conflict and uses /etc/php5 for configuration. There is no technical reason why this should not be possible to be versioned but it raises some questions for CLI. One would probably also want pear53, pear54 as each distributed php brings its pear. Would you want to package pear libraries to suit these separate pears? Should I automagically move/upgrade configs, libraries and extensions when upgrading to a new PHP instance or should I leave the configs in the old place where they are no longer read by the new PHP/extension binaries? It would clutter the namespace a bit. It's all resolvable for the distribution maintainers, but is it worth it? -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
OK, let's try this again. Maybe language versioning is out. That's sad, but this thread brought to light a much more important problem I would like to try to address. I have long felt the PHP team is living in another world I do. Let me describe my world. I am working on an open source package. So does another 1000 or so developers. And another 10 000 adds modules (or maybe you'd call them plugins). I do not even know how many then adds custom, site specific code. This whole pile of software forms an ecosystem which is quite sizeable. The software is somewhat popular. Users form a pyramid. The bottom is shared hosts. Shared hosts that we need to take into consideration. So if the shared world just barely switched to 5.3 default then, alas, we can't release a version that requires PHP 5.4 because there is no shared support for it. Also, it worths mentioning that one of the more popular server OSes, Ubuntu LTS also doesn't have a PHP 5.4 yet. Without software demanding 5.4, hosts won't upgrade. This is a vicious circle that is superb hard to break. I was told in this thread that the new release process solves this and it is our and our users role to explain that to their ISPs, admins, etc. Well, what am I to explain? As I mentioned previously, if a shared host does a PHP upgrade and their users see new error messages, then the host have a support problem. When I tried to point this out, I got strawman arguments (about segfaults and bugfixes which breaking forward compatibility and absolutely having nothing to do with BC) and ridicule (the problem is with your code). You can ridicule the codebase all you want, but the codebase a) works b) tested. This doesn't change the fact that breaking backwards compatibility a little is like being a little pregnant. Either you are or you are not and currently you are not. This is sad because apparently a lot of work is being put into this and then on a minor point it falls short of the goal. It would make everyone's life so much easier if all the Drupal 8 code that is being written and tested with 5.4 would just work 5.5 without *any* problem. I would absolutely love not to have this conversation again three years from now when we need to decide to ship Drupal 9 with PHP 5.5 or 5.4 -- because we could indeed do a campaign when 5.4 is due to change to 5.5 outright because it won't break BC with 5.4. Is this absolutely unattainable? Best regards Karoly Negyesi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/04/2013 10:35 PM, Karoly Negyesi wrote: OK, let's try this again. Maybe language versioning is out. That's sad, but this thread brought to light a much more important problem I would like to try to address. I have long felt the PHP team is living in another world I do. Let me describe my world. I am working on an open source package. So does another 1000 or so developers. And another 10 000 adds modules (or maybe you'd call them plugins). I do not even know how many then adds custom, site specific code. This whole pile of software forms an ecosystem which is quite sizeable. The software is somewhat popular. Users form a pyramid. The bottom is shared hosts. Shared hosts that we need to take into consideration. So if the shared world just barely switched to 5.3 default then, alas, we can't release a version that requires PHP 5.4 because there is no shared support for it. Also, it worths mentioning that one of the more popular server OSes, Ubuntu LTS also doesn't have a PHP 5.4 yet. Without software demanding 5.4, hosts won't upgrade. This is a vicious circle that is superb hard to break. I was told in this thread that the new release process solves this and it is our and our users role to explain that to their ISPs, admins, etc. Well, what am I to explain? As I mentioned previously, if a shared host does a PHP upgrade and their users see new error messages, then the host have a support problem. When I tried to point this out, I got strawman arguments (about segfaults and bugfixes which breaking forward compatibility and absolutely having nothing to do with BC) and ridicule (the problem is with your code). You can ridicule the codebase all you want, but the codebase a) works b) tested. This doesn't change the fact that breaking backwards compatibility a little is like being a little pregnant. Either you are or you are not and currently you are not. This is sad because apparently a lot of work is being put into this and then on a minor point it falls short of the goal. It would make everyone's life so much easier if all the Drupal 8 code that is being written and tested with 5.4 would just work 5.5 without *any* problem. Yup, so please test it against 5.5 now. Have you done so? It is rather trivial to do. Grab it from git or there is a tarball at http://qa.php.net I would absolutely love not to have this conversation again three years from now when we need to decide to ship Drupal 9 with PHP 5.5 or 5.4 -- because we could indeed do a campaign when 5.4 is due to change to 5.5 outright because it won't break BC with 5.4. Is this absolutely unattainable? Yes, I would say it is unattainable. You are essentially asking that we don't make any changes. Nothing that could possibly affect existing code down to and including any potential warning messages even if that code is obviously incorrect, insecure and/or not doing what the developer intended. That means no new keywords, no new notices, no bug fixes. What exactly can we do in a new version then? Just as a point of reference, the array to string conversion notice that was added in 5.4, which seems to be at the center of your argument, has found 6 potential bugs across 3 different companies I work closely with. This was a good and useful change to a large part of our userbase. You should also recognize that there is also a large faction that wants to see us make even more drastic changes along these lines and not less. We have to try to balance both ends of this spectrum. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposal for serious BC compatibility aka language versioning
Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. Regards, Karoly Negyesi
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
hi, On Sun, Feb 3, 2013 at 12:36 PM, Karoly Negyesi kar...@negyesi.net wrote: Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. We have been there, no chance to go back again with such tags. Also the new release process RFC (https://wiki.php.net/rfc/releaseprocess) solves the BC issues between minor updates (5.4 to 5.5, or 5.3 to 5.4 f.e.). It is our and our users role to explain that to their ISPs, admins, etc. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Well, either I misunderstood the policy or it's broken. Here are some (note: please do not argue whether these are more correct than before, they very well might be but they broke backwards compatibility): For example, in 5.4 array_diff_assoc began to throw a notice when casting to string. Again in 5.4, using a string offset against a string throws a warning. It wasn't doing that before. If you want I can dig around in our issue queue for more backwards compatibility breaks but there are some. Regards, Karoly Negyesi On Sun, Feb 3, 2013 at 4:19 AM, Pierre Joye pierre@gmail.com wrote: hi, On Sun, Feb 3, 2013 at 12:36 PM, Karoly Negyesi kar...@negyesi.net wrote: Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. We have been there, no chance to go back again with such tags. Also the new release process RFC (https://wiki.php.net/rfc/releaseprocess) solves the BC issues between minor updates (5.4 to 5.5, or 5.3 to 5.4 f.e.). It is our and our users role to explain that to their ISPs, admins, etc. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 11:44 AM, Karoly Negyesi wrote: Well, either I misunderstood the policy or it's broken. Here are some (note: please do not argue whether these are more correct than before, they very well might be but they broke backwards compatibility): For example, in 5.4 array_diff_assoc began to throw a notice when casting to string. Again in 5.4, using a string offset against a string throws a warning. It wasn't doing that before. We do not consider a change in warnings/notices a BC break. I realize for certain test frameworks and custom error handlers it could break things if they are expecting a specific warning or lack of warning, but the code itself behaves exactly as it did before and as such there is no BC break. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Sun, Feb 3, 2013 at 8:44 PM, Karoly Negyesi kar...@negyesi.net wrote: Well, either I misunderstood the policy or it's broken. Here are some (note: please do not argue whether these are more correct than before, they very well might be but they broke backwards compatibility): For example, in 5.4 array_diff_assoc began to throw a notice when casting to string. Again in 5.4, using a string offset against a string throws a warning. It wasn't doing that before. If you want I can dig around in our issue queue for more backwards compatibility breaks but there are some. Regards, Karoly Negyesi As Rasmus mentioned before our current release policy allows warnings/etc. to be added in a minor release. If this is the same test that you mentioned before on irc, then one could argue that this change was useful as it helped you spot and error in you testsuite (comparing a multi-dimensional array using array_diff_assoc which not comparing the arrays but the string Array. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Sun, Feb 3, 2013 at 2:50 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/03/2013 11:44 AM, Karoly Negyesi wrote: Well, either I misunderstood the policy or it's broken. Here are some (note: please do not argue whether these are more correct than before, they very well might be but they broke backwards compatibility): For example, in 5.4 array_diff_assoc began to throw a notice when casting to string. Again in 5.4, using a string offset against a string throws a warning. It wasn't doing that before. We do not consider a change in warnings/notices a BC break. I realize for certain test frameworks and custom error handlers it could break things if they are expecting a specific warning or lack of warning, but the code itself behaves exactly as it did before and as such there is no BC break. I for one think this point needs to be communicated a lot more clearly, because when I attempted to introduce a patch that would throw E_DEPRECATED warning for mcrypt last year I was told it could not be merged in 5.4 since it would cause a BC break. Later someone else disagreed with that. So clearly not everyone seems to be inline. /my two cents -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
We do not consider a change [...] a BC break Let me help: backwards compatibility means a host can upgrade a package without inducing a lot of support tickets. Best, Karoly Negyesi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 01:48 PM, Karoly Negyesi wrote: We do not consider a change [...] a BC break Let me help: backwards compatibility means a host can upgrade a package without inducing a lot of support tickets. Well, that is obviously not realistic. Every change we make has some level of BC impact. We have to draw a line somewhere. Heck, even fixing a segfault is technically a BC change because the behaviour from one version to the next is different. A 100% strict no BC rule would mean we couldn't actually ever fix any bugs. There has to be a line. Our line is that in minor version upgrades we won't change documented functional behaviour unless there are extremely serious (usually security-related) reasons for doing so. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Well, fixing a segfault, adding a new function or method as it oft happened in PHP 5.3 is only breaking forwards compatibility not backwards -- if you have code that ran on PHP 5.3.4 it'll run on 5.3.5. The reverse is not true which causes some headaches to Drupal developers but it's not relevant to this discussion. So, what about adding a version string to the opening ?php tag so that you can fix bugs while not breaking BC :P ? On Sun, Feb 3, 2013 at 1:55 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/03/2013 01:48 PM, Karoly Negyesi wrote: We do not consider a change [...] a BC break Let me help: backwards compatibility means a host can upgrade a package without inducing a lot of support tickets. Well, that is obviously not realistic. Every change we make has some level of BC impact. We have to draw a line somewhere. Heck, even fixing a segfault is technically a BC change because the behaviour from one version to the next is different. A 100% strict no BC rule would mean we couldn't actually ever fix any bugs. There has to be a line. Our line is that in minor version upgrades we won't change documented functional behaviour unless there are extremely serious (usually security-related) reasons for doing so. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 02:03 PM, Karoly Negyesi wrote: Well, fixing a segfault, adding a new function or method as it oft happened in PHP 5.3 is only breaking forwards compatibility not backwards -- if you have code that ran on PHP 5.3.4 it'll run on 5.3.5. The reverse is not true which causes some headaches to Drupal developers but it's not relevant to this discussion. So, what about adding a version string to the opening ?php tag so that you can fix bugs while not breaking BC :P ? We had that in the past and it was a mess. We are not going to make that mistake again. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
If you mean ?php3 then well, I was not here but maybe we could learn from the mistakes and get a better implementation? I have some ideas, but first I'd be glad to learn why it was a mess. On Sun, Feb 3, 2013 at 2:06 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 02/03/2013 02:03 PM, Karoly Negyesi wrote: Well, fixing a segfault, adding a new function or method as it oft happened in PHP 5.3 is only breaking forwards compatibility not backwards -- if you have code that ran on PHP 5.3.4 it'll run on 5.3.5. The reverse is not true which causes some headaches to Drupal developers but it's not relevant to this discussion. So, what about adding a version string to the opening ?php tag so that you can fix bugs while not breaking BC :P ? We had that in the past and it was a mess. We are not going to make that mistake again. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. Agreed with the others that this should not go into the engine (and this should also not really clutter up the Internals list), but if you have a real need for running different versions of PHP for different URLs, you could pretty easily set up multiple FPM backends (one for each version you support) and have Nginx map URLs to these. It would be a maintenance headache, but not the disaster this would be if it had to be maintained in PHP-proper. S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 02:11 PM, Karoly Negyesi wrote: If you mean ?php3 then well, I was not here but maybe we could learn from the mistakes and get a better implementation? I have some ideas, but first I'd be glad to learn why it was a mess. The whole concept of maintaining multiple personalities in the same codebase is a complete non-starter. The complexity that leads to is mindnumbing. There really isn't anything to discuss along these lines. It will not happen. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Sun, Feb 3, 2013 at 12:36 PM, Karoly Negyesi kar...@negyesi.net wrote: Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. Regards, Karoly Negyesi At least two points why this makes no sense whatsoever: 1) One would have to maintain or at least keep around all previous versions of the engine and the libraries. That would be a shitload of cruft and a lot of maintenance work. 2) Different behavior per-file is not feasible as components in both files interact. If you have one ?php6 file and one ?php5 file and both interact (like, you know, calling a function from one file in the other one) you will have a pretty hard time decided what behavior this should result in. The ?php6 behavior or the ?php5 one? So something like this can only be done on a per-request basis (rather than per-file). And to do this on a per-request basis you already have all the means. Just run two different PHP versions. No issue with that; doesn't require no further support from PHP. Nikita
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Hm, there is a slight miscommunication which is my fault. I do not suggest a PHP engine being compatible with 5 and 6, gosh, no. I suggest a PHP engine compatible with 5.3 and 5.4. Is that a maintenance mess too? The difference should be a lot, lot smaller. And yes, interaction is a problem and again I'd be glad to discuss on how to behave for those. Regards NK On Sun, Feb 3, 2013 at 2:22 PM, Nikita Popov nikita@gmail.com wrote: On Sun, Feb 3, 2013 at 12:36 PM, Karoly Negyesi kar...@negyesi.net wrote: Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. Regards, Karoly Negyesi At least two points why this makes no sense whatsoever: 1) One would have to maintain or at least keep around all previous versions of the engine and the libraries. That would be a shitload of cruft and a lot of maintenance work. 2) Different behavior per-file is not feasible as components in both files interact. If you have one ?php6 file and one ?php5 file and both interact (like, you know, calling a function from one file in the other one) you will have a pretty hard time decided what behavior this should result in. The ?php6 behavior or the ?php5 one? So something like this can only be done on a per-request basis (rather than per-file). And to do this on a per-request basis you already have all the means. Just run two different PHP versions. No issue with that; doesn't require no further support from PHP. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 02:27 PM, Karoly Negyesi wrote: Hm, there is a slight miscommunication which is my fault. I do not suggest a PHP engine being compatible with 5 and 6, gosh, no. I suggest a PHP engine compatible with 5.3 and 5.4. Is that a maintenance mess too? The difference should be a lot, lot smaller. And yes, interaction is a problem and again I'd be glad to discuss on how to behave for those. It doesn't matter which versions you are talking about. Any sort of multiple-personality support would turn into a complete maintenance nightmare. We try to move things along at a responsible pace in the direction that we want things to go. Sometimes that involves some pain. And yes, sometimes we don't always realize that there is code out there relying certain things. Like the fact that Drupal relied on array_diff_asccoc() comparing array(1,2,3) to Array and saying those were equivalent without any sort of notice. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
array_diff_asccoc() comparing array(1,2,3) to Array and saying those were equivalent without any sort of notice. That's not what happened, some contib was comparing array(1,2,3) to array(1,2,array(3)) and even looking at the documentation it is not clear whether the cast should or should not throw a notice. But, if that's desired behavior, I will add a note to warn people. Best Karoly Negyesi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 02:39 PM, Karoly Negyesi wrote: array_diff_asccoc() comparing array(1,2,3) to Array and saying those were equivalent without any sort of notice. That's not what happened, some contib was comparing array(1,2,3) to array(1,2,array(3)) and even looking at the documentation it is not clear whether the cast should or should not throw a notice. But, if that's desired behavior, I will add a note to warn people. The cast should always throw a notice. The function is documented to only compare single-dimensional arrays, so if you pass it a multi-dimensional array it is going to treat them as a single dimensional and the only way to do that is to cast them to scalars. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Sun, Feb 3, 2013 at 11:22 PM, Nikita Popov nikita@gmail.com wrote: On Sun, Feb 3, 2013 at 12:36 PM, Karoly Negyesi kar...@negyesi.net wrote: Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. Regards, Karoly Negyesi At least two points why this makes no sense whatsoever: 1) One would have to maintain or at least keep around all previous versions of the engine and the libraries. That would be a shitload of cruft and a lot of maintenance work. 2) Different behavior per-file is not feasible as components in both files interact. If you have one ?php6 file and one ?php5 file and both interact (like, you know, calling a function from one file in the other one) you will have a pretty hard time decided what behavior this should result in. The ?php6 behavior or the ?php5 one? So something like this can only be done on a per-request basis (rather than per-file). And to do this on a per-request basis you already have all the means. Just run two different PHP versions. No issue with that; doesn't require no further support from PHP. Nikita Just run two different PHP versions. Using Debian/Ubuntu, I have python2.6, python2.7 and python3 packages, but only one version of php5-fpm. Maybe it would be better to have php5.3-fpm and php5.4-fpm, using /etc/php5.3 and /etc/php5.4 ? Esp. for Travis-CI it would be much better to have separate packages than running custom workarounds. Regards, Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 02/03/2013 02:49 PM, Thomas Bley wrote: On Sun, Feb 3, 2013 at 11:22 PM, Nikita Popov nikita@gmail.com wrote: On Sun, Feb 3, 2013 at 12:36 PM, Karoly Negyesi kar...@negyesi.net wrote: Hi, So, if we are talking about PHP 6, then the opening ?php tag should be accompanied by the version it was written for, it was tested with and then the engine could switch to a compatibility mode for that version. Seems to me that this would solve the problem where a host can't upgrade to a more modern version for fear of breaking old code. Consequently, open source packages -- like Drupal I am deeply involved with -- can't use more modern PHP versions decreasing the push for hosts to upgrade. This is a devilish circle and it'd be great to break it. Regards, Karoly Negyesi At least two points why this makes no sense whatsoever: 1) One would have to maintain or at least keep around all previous versions of the engine and the libraries. That would be a shitload of cruft and a lot of maintenance work. 2) Different behavior per-file is not feasible as components in both files interact. If you have one ?php6 file and one ?php5 file and both interact (like, you know, calling a function from one file in the other one) you will have a pretty hard time decided what behavior this should result in. The ?php6 behavior or the ?php5 one? So something like this can only be done on a per-request basis (rather than per-file). And to do this on a per-request basis you already have all the means. Just run two different PHP versions. No issue with that; doesn't require no further support from PHP. Nikita Just run two different PHP versions. Using Debian/Ubuntu, I have python2.6, python2.7 and python3 packages, but only one version of php5-fpm. Maybe it would be better to have php5.3-fpm and php5.4-fpm, using /etc/php5.3 and /etc/php5.4 ? Esp. for Travis-CI it would be much better to have separate packages than running custom workarounds. Nothing stops you from doing that. Compile as many versions as you want with different --with-config-file-path settings. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On 03.02.2013 23:49, Thomas Bley wrote: Using Debian/Ubuntu, I have python2.6, python2.7 and python3 packages, but only one version of php5-fpm. Maybe it would be better to have php5.3-fpm and php5.4-fpm, using /etc/php5.3 and /etc/php5.4 ? Esp. for Travis-CI it would be much better to have separate packages than running custom workarounds. I don't think you'd find many people here disagreeing with distribution maintainers providing packages for multiple version at the same time (like 5.3 and 5.4) - so that suggestion should be brought to these people. (I know, some are reading this list.) I've never seen anyone on this list telling a distribution maintainer not to use /etc/php5.3 or something, please enlighten me if that's not the case. Greetings, Florian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Sun, Feb 3, 2013 at 1:48 PM, Karoly Negyesi kar...@negyesi.net wrote: We do not consider a change [...] a BC break Let me help: backwards compatibility means a host can upgrade a package without inducing a lot of support tickets. Best, Karoly Negyesi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php As Rasmus already pointed out, 100% backwards compatibility is simply unrealistic. You would also be hard-pressed to find any scripting language out there that puts as much focus on maintaining BC as PHP does. Personally, I think we worry about it a little too much when it comes to major version changes. If you write your code to be scalable and have at least some sliver of forward compatibility, then minor changes like notices and warnings should not cause your codebase to blow up in your face. If they are causing that and fixing it would require a lot of support tickets, as you put it, then I think the problem is with your code, not PHP. You should always anticipate possible changes in the language when writing your code if you plan on upgrading to the latest versions of the language. There is a simple solution for maintaining 100% BC: Don't upgrade PHP. Same goes for Perl, Python, Java, etc. If your code isn't forward compatible, just target it to the version it was written for and you're good to go. If you want people to be able to upgrade PHP, then you have to do your part by making your code scalable at least to a reasonable degree. I think we already do more than our part with how careful we are about behavioral changes in minor version increments. I also agree that different tags for different versions is just impractical and represents a maintenance nightmare. But if you really want to go forward with your suggestion, write an RFC to be voted on. I'd be happy to publish it to the wiki on your behalf, though I won't be voting for it. --Kris
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
On Sun, Feb 3, 2013 at 11:56 PM, Florian Anderiasch m...@anderiasch.de wrote: On 03.02.2013 23:49, Thomas Bley wrote: Using Debian/Ubuntu, I have python2.6, python2.7 and python3 packages, but only one version of php5-fpm. Maybe it would be better to have php5.3-fpm and php5.4-fpm, using /etc/php5.3 and /etc/php5.4 ? Esp. for Travis-CI it would be much better to have separate packages than running custom workarounds. I don't think you'd find many people here disagreeing with distribution maintainers providing packages for multiple version at the same time (like 5.3 and 5.4) - so that suggestion should be brought to these people. (I know, some are reading this list.) I've never seen anyone on this list telling a distribution maintainer not to use /etc/php5.3 or something, please enlighten me if that's not the case. Greetings, Florian If I see it correctly, none of Debian, Ubuntu, openSUSE, CentOS, Fedora currently offer more than one version of PHP. The majority of the stable/lts distributions is currently on 5.3.x. Getting packages for different versions and the ability to run them in parallel might also give a push in testing alphas. Regards, Thomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/02/13 23:56, Florian Anderiasch wrote: On 03.02.2013 23:49, Thomas Bley wrote: Using Debian/Ubuntu, I have python2.6, python2.7 and python3 packages, but only one version of php5-fpm. Maybe it would be better to have php5.3-fpm and php5.4-fpm, using /etc/php5.3 and /etc/php5.4 ? Esp. for Travis-CI it would be much better to have separate packages than running custom workarounds. I don't think you'd find many people here disagreeing with distribution maintainers providing packages for multiple version at the same time (like 5.3 and 5.4) - so that suggestion should be brought to these people. (I know, some are reading this list.) I've never seen anyone on this list telling a distribution maintainer not to use /etc/php5.3 or something, please enlighten me if that's not the case. Gentoo has allowed its users to install multiple versions of PHP for a few years now, and also running multiple versions of php-fpm in parallel. So far it has not been that much of a problem to maintain, seemingly much easier than offering the same for ruby or python. - -- Ole Markus -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJRD1o8AAoJEGurSuXEqSv12rgH/j39u30ONtvZnarsuC9A6Pjp j/xjVTUrIIeNNKAjXQPxc8XgfJ9QBOTZxaZ6ZtocUMe4sLrwukal2o/njM7kmhSc VYpbhNYDbExX0Rq/7qMQn8fUialoOb45sv2RsCmCk6Abx4NRWPmLYMGU/FLUYwcS TBKHevQ6VsYDu/G85W26iyA3jpk8RTRk42mwrAtIePl0gNcpmbVHrNXhjhHF5tbB RRm5lHvpM2BO38xSh+wAqk+sqNuTTwj3elOGKhMbwICEzHIaIiaqq+Gu4jVwsAke Zz8R4qtfMXE4hDwIezIukAgye2GpK5WRe3wG9czMyO+xrv5Y+KkP3lRwobkxbeo= =2+mI -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
Thomas Bley in php.internals (Mon, 4 Feb 2013 02:06:02 +0100): If I see it correctly, none of Debian, Ubuntu, openSUSE, CentOS, Fedora currently offer more than one version of PHP. Directadmin does, I am using it on CentOS. http://forum.directadmin.com/showthread.php?t=44743 Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
