# 5.3 Backwards Compatibility - Thread: https://externals.io/message/40391 - Original archive: https://news-web.php.net/php.internals/40391 - Started by Lester Caine on 2008-09-09T04:05:38+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 --- ## #40391 — Lester Caine — 2008-09-09T04:05:38+00:00 URL: https://externals.io/message/40391#40391 While I have loaded 5.3.? changing any of my existing code base to remove warnings is not likely to happen any time soon since compatibility with users who are still running older versions of PHP still needs to be maintained. I've got http://wiki.php.net/doc/scratchpad/upgrade/53 which seems to be currently the only reference to changes? But where do I find the detail on how things ARE currently implemented such as namespace and (fingers down throat) goto? Another major concern here since maintaining BC with *PHP4* is still an unfortunate current requirement in the field is what happens when PEAR actually uses namespace and other 5.3 only features. HOW will we manage accessing versions of PEAR that are compatible with our active codebase and so ensure that we have compatible sets of packages? Personally I can't stand the CURRENT problems that is caused by not knowing which version of a PEAR extension users actually have and in order to ensure a COMPATIBLE version, but in future will the PEAR installer pick up a correct version for the copy of PHP actually being run? I get the distinct impression that those pushing for PHP5.3 are simply not making a good case for many of us to even want to follow them down that path? It almost feels like this is a DIFFERENT path to the main stream of PHP6 which many of us are much more desperate to be testing in the field, which seems to have become an ignored backwater? Key elements which have been flagged to PHP6 ( such as BIGINT ) are on hold while new concepts which were not part of the PHP6 reoadmap have been forced through? Since current hardware *IS* 64 bit, actually handling 64 bit numbers properly would be nice :) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #40393 — Greg Beaver — 2008-09-09T05:15:29+00:00 URL: https://externals.io/message/40391#40393 · In reply to: #40391 Hi Lester, Lester Caine wrote: > While I have loaded 5.3.? changing any of my existing code base to > remove warnings is not likely to happen any time soon since > compatibility with users who are still running older versions of PHP > still needs to be maintained. > > I've got http://wiki.php.net/doc/scratchpad/upgrade/53 which seems to be > currently the only reference to changes? But where do I find the detail > on how things ARE currently implemented such as namespace and (fingers > down throat) goto? the manual is ridiculously up to date, and is the best reference location for new features. Occasionally things are documented within seconds of commit and in one case *prior* to commit. It's frightening what they do :). > Another major concern here since maintaining BC with *PHP4* is still an > unfortunate current requirement in the field is what happens when PEAR > actually uses namespace and other 5.3 only features. HOW will we manage > accessing versions of PEAR that are compatible with our active codebase > and so ensure that we have compatible sets of packages? This and the following paragraph are questions for PEAR, and don't concern internals developers, pear-dev@lists.php.net is the best list for tech questions like the ones you raise. However, I will say that PEAR has been doing just fine with the handling of PHP version differences to date. The installer is fully aware of PHP version dependency, and refuses to install packages that are incompatible with your PHP version. If you find an older package that has an incompatibility with a newer PHP version, this is considered a bug in the package that must be fixed (again, a PEAR problem, not a PHP problem). However, if you upgrade PHP, it is best to upgrade the existing packages to be sure you have ones compatible with the current PHP release. This is a tricky problem, but fortunately the most-used PEAR packages are carefully tracked against PHP releases by their maintainers, so we have not had a PHP version-related problem since the move to 5.0. > Personally I can't stand the CURRENT problems that is caused by not > knowing which version of a PEAR extension users actually have and in > order to ensure a COMPATIBLE version, but in future will the PEAR > installer pick up a correct version for the copy of PHP actually being run? "pear list" show the version information you need, and PEAR since version 1.6.0 takes into account PHP version prior to download (1.6.0 was released June 7, 2007) > I get the distinct impression that those pushing for PHP5.3 are simply > not making a good case for many of us to even want to follow them down > that path? It almost feels like this is a DIFFERENT path to the main > stream of PHP6 which many of us are much more desperate to be testing in > the field, which seems to have become an ignored backwater? Key elements > which have been flagged to PHP6 ( such as BIGINT ) are on hold while new > concepts which were not part of the PHP6 reoadmap have been forced > through? Since current hardware *IS* 64 bit, actually handling 64 bit > numbers properly would be nice :) I think I have made an excellent case for the things that I care about in 5.3. ;) Greg --- ## #40394 — Lester Caine — 2008-09-09T06:05:02+00:00 URL: https://externals.io/message/40391#40394 · In reply to: #40393 Greg Beaver wrote: > Hi Lester, > > Lester Caine wrote: > > […] > > the manual is ridiculously up to date, and is the best reference > location for new features. Occasionally things are documented within > seconds of commit and in one case *prior* to commit. It's frightening > what they do :). Trying to follow on from 'scratchpad' using php.net search namespace - not found - AH - namespaces ... goto not found Closure - not found Don't have time to spend hours finding the information. It takes long enough to create a safe environment to copy things to. > > […] OK usual thing :( - not my problem But in order to TEST PHP5.3 one needs a complete set of packages used WITH ones application - without damaging the working copies of PHP and this is easier if one CAN simply create a working set of files without having to monitor downloads. Some key features that were available in PHP seem only to be available in PEAR now :( > > […] > > I think I have made an excellent case for the things that I care about > in 5.3. Making a case that you like something and convincing people that there is some point in our using it a different matter. I can see the reason for namespace, but I have yet to be convinced that the current implementation is not just a bodge job since there seems to be so many holes in it still :( I thought PHP5 OO was about creating and using classes to ring fence stuff so why do we now need to ring fence the ring fence? But of cause the main problem is that the major part of the PHP code base has to to be converted TO OO? So most stuff we are working with is simply not PHP5 friendly yet? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #40395 — Kalle Sommer Nielsen — 2008-09-09T06:14:47+00:00 URL: https://externals.io/message/40391#40395 · In reply to: #40394 Hi Lester 2008/9/9 Lester Caine > Greg Beaver wrote: > > > […] > Trying to follow on from 'scratchpad' using php.net search > namespace - not found - AH - namespaces ... I guess an alias could be made for that if its that big a need :) > > goto not found > Closure - not found These things are currently on the documentation team's todo after the alpha releases as far as Im aware of. > > Don't have time to spend hours finding the information. It takes long > enough to create a safe environment to copy things to. > > Another major concern here since maintaining BC with *PHP4* is still an > > […] > OK usual thing :( - not my problem > But in order to TEST PHP5.3 one needs a complete set of packages used WITH > ones application - without damaging the working copies of PHP and this is > easier if one CAN simply create a working set of files without having to > monitor downloads. Some key features that were available in PHP seem only to > be available in PEAR now :( > > I get the distinct impression that those pushing for PHP5.3 are simply > > […] > Making a case that you like something and convincing people that there is > some point in our using it a different matter. I can see the reason for > namespace, but I have yet to be convinced that the current implementation is > not just a bodge job since there seems to be so many holes in it still :( > I thought PHP5 OO was about creating and using classes to ring fence stuff > so why do we now need to ring fence the ring fence? But of cause the main > problem is that the major part of the PHP code base has to to be converted > TO OO? So most stuff we are working with is simply not PHP5 friendly yet? > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/lsces/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php > > -- > > > > -- Kalle Sommer Nielsen --- ## #40397 — Hannes Magnusson — 2008-09-09T07:25:01+00:00 URL: https://externals.io/message/40391#40397 · In reply to: #40394 > > Trying to follow on from 'scratchpad' using php.net search > namespace - not found - AH - namespaces ... Fixed, but why don't you try to raise this issue on remotely closer mailinglist or bug report? > goto not found Help appreciated. > Closure - not found "The RFC can serve as documentation until someone can document it" is the new cool today. > Don't have time to spend hours finding the information. It takes long enough Happ shittens. Any and all help is very appreciated. -Hannes --- ## #40399 — Lester Caine — 2008-09-09T08:18:45+00:00 URL: https://externals.io/message/40391#40399 · In reply to: #40397 Hannes Magnusson wrote: > > > […] > > Fixed, but why don't you try to raise this issue on remotely closer > mailinglist or bug report? > > > […] > Help appreciated. 'Over my dead body' comes to mind ;) The NOTES (2005?) I have relating to this do cover the intended plan, but in order to document it one needs to know how it was actually implemented? It's not something I would consider using, but as soon as it appears in libraries one has to understand how it works if one gets dragged in by faults. However if the original plan have been followed, then it's not actually goto is it? > > […] > > "The RFC can serve as documentation until someone can document it" is > the new cool today. > > > […] > > Happ shittens. > Any and all help is very appreciated. Greg's blanket - It's in the manual was simply wrong? TESTING new features requires that we know that they are there and how they work? But raising a lot more bugs for things that ARE still being padded out is not the right way of getting the information so we can test? The current problem is that a lot of the material has NOT been pushed back to php.net yet - it still says that is to be done ... so one has to find these extra bits. 5.3.0 has not been released yet, and where data IS in the manual it's marked as 'experimental' ( namespaces ... ) so what is a more appropriate list for matters relating to getting 5.3.0 out of the door in a format that we can actually use? I'm trying to keep a copy of 5.3 running along side my production 5.2 machines in order to test things out, and I have a list of things which need 'fixing' in the applications I am using *IF* I'm to use 5.3 in production, but that can't happen until it leaves 'internals' and becomes a version actually supported on the other lists? For the moment I keep watching here and checking for updates to the information. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #40401 — Steph Fox — 2008-09-09T12:47:46+00:00 URL: https://externals.io/message/40391#40401 · In reply to: #40394 But of cause the main problem > is that the major part of the PHP code base has to to be converted TO OO? Why? - Steph --- ## #40402 — Pierre Joye — 2008-09-09T12:59:44+00:00 URL: https://externals.io/message/40391#40402 · In reply to: #40394 hi Lester, > Don't have time to spend hours finding the information. It takes long enough > to create a safe environment to copy things to. Talking about not having the time, I suppose you did not have the time either to deal with firebird as discussed a while back? Nothing changed so far and nothing is going to change anytime soon if nobody steps in. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #40406 — Greg Beaver — 2008-09-09T13:57:13+00:00 URL: https://externals.io/message/40391#40406 · In reply to: #40394 Lester Caine wrote: > OK usual thing :( - not my problem > But in order to TEST PHP5.3 one needs a complete set of packages used > WITH ones application - without damaging the working copies of PHP and > this is easier if one CAN simply create a working set of files without > having to monitor downloads. Some key features that were available in > PHP seem only to be available in PEAR now :( Lester I mean no disrespect to you with my next rather blunt comment: I have absolutely no idea what key features you are talking about here. If it is important, and the features really are missing, you have 2 recourses 1) do something 2) complain Only 1 actually accomplishes anything. > > […] > Making a case that you like something and convincing people that there > is some point in our using it a different matter. I can see the reason > for namespace, but I have yet to be convinced that the current > implementation is not just a bodge job since there seems to be so many > holes in it still :( I was referring to ext/phar, but there is no way you could have known that from my snide comment. I was also referring to the multiple tweaks to namespaces, as it is my personal quest to make them a little more user-friendly (from my perspective) than they are right now. I happen to believe that a good feature doesn't *need* much advocacy beyond documentation for people to use it, and both ext/phar and namespaces do have documentation. Of course, any problems found in the docs during this alpha phase should immediately be reported at bugs.php.net where they will be fixed (read: not here, where they create noise), including abstract structural issues with the organization or confusing language. > I thought PHP5 OO was about creating and using classes to ring fence > stuff so why do we now need to ring fence the ring fence? But of cause > the main problem is that the major part of the PHP code base has to to > be converted TO OO? So most stuff we are working with is simply not PHP5 > friendly yet? I can't answer to this point, as my assumption about PHP5 OO was that it is about fixing some of the gotchas in PHP4 OO, not about shoehorning everything in PHP to fit into the OO box. Thanks, Greg --- ## #40408 — Lester Caine — 2008-09-09T14:28:33+00:00 URL: https://externals.io/message/40391#40408 · In reply to: #40402 Pierre Joye wrote: > hi Lester, > > > > > […] > > Talking about not having the time, I suppose you did not have the time > either to deal with firebird as discussed a while back? Nothing > changed so far and nothing is going to change anytime soon if nobody > steps in. I test everything when I can as it is updated, but as yet I have had no need to change anything. I STILL have not got to a state where I can do much on the windows side, and have no intention on using M$ compilers on the development machines, but I DO now have the php_interbase code into PHPEclipse on Linux and can at least play with it. I've just done two big upgrades which use Apache2/FB2/PHP5.2.6 at this stage and that is unlikely to be moved to PHP5.3 as we will leave things alone now that it is running. They are on private networks so the PEAR bits has had to be 'imported', and the IT departments like to block my ability to change things once the systems are live. It's native Unicode and Firebird that we need to work on hence the wish to start playing with at least an alpha of PHP6 rather than spending time re-testing things in PHP5.X :( php_interbase passes all my tests fine now so what still needs doing? ( And I think my posts to internals@ are now being blocked ? ) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #40411 — Lester Caine — 2008-09-09T15:07:26+00:00 URL: https://externals.io/message/40391#40411 · In reply to: #40406 Greg Beaver wrote: > Lester Caine wrote: > > […] > > Lester I mean no disrespect to you with my next rather blunt comment: I > have absolutely no idea what key features you are talking about here. > If it is important, and the features really are missing, you have 2 > recourses Main problem here - I think - is that in the past I managed to work without PEAR, but increasingly I'm finding some PEAR package needs to be installed to do things which in the past simply worked :( Since the customer sites are secure without internet access, simply downloading things via the installer does not work. This may simply be because libraries that included some of this stuff are now simply switching to PEAR instead. > 1) do something I create my own local copies and install from that. Nothing else I can do and nothing I can contribute since there is no interest in that approach .... I can then freeze a copy that works with the server configuration and I'm not messed up as I have been in the past because something gets changed. > 2) complain > > Only 1 actually accomplishes anything. > > > […] > > I was referring to ext/phar, but there is no way you could have known > that from my snide comment. I was also referring to the multiple tweaks > to namespaces, as it is my personal quest to make them a little more > user-friendly (from my perspective) than they are right now. I happen > to believe that a good feature doesn't *need* much advocacy beyond > documentation for people to use it, and both ext/phar and namespaces do > have documentation. Of course, any problems found in the docs during > this alpha phase should immediately be reported at bugs.php.net where > they will be fixed (read: not here, where they create noise), including > abstract structural issues with the organization or confusing language. phar is something else I do not so any advantage to using. So as long as it's not 'turned on by default' like a few other other sections of PHP5.3 have been then no problem, but packaging 100Mb of bitweaver in a single code file just seems wrong to me? And the biggest pain with Java JAR's is having to rebuild everything every time you want to make a simple change. OK they may make sense for libraries, but again we have to re-package every time we want to tweak things. I came to PHP BECAUSE I wanted to get away from compiled and processed code and the ability to drop new sections in on the fly is one of it's main advantages. > > […] > > I can't answer to this point, as my assumption about PHP5 OO was that it > is about fixing some of the gotchas in PHP4 OO, not about shoehorning > everything in PHP to fit into the OO box. Most of the code that I am working on is a miss-mash of PHP4 code with classes added and other 'packages' of code. Steph - the code does not need converting to OO, but it does make sense to continue that progress on areas that have yet to be converted. I'm just seeing 'namespaces' as a means of wrapping non-OO code rather than tidying it up into classes, and the current comments seem to imply that they are not really set up even to do that yet? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #40413 — Alexey Zakhlestin — 2008-09-09T15:40:57+00:00 URL: https://externals.io/message/40391#40413 · In reply to: #40411 > Main problem here - I think - is that in the past I managed to work without > PEAR, but increasingly I'm finding some PEAR package needs to be installed > to do things which in the past simply worked :( Since the customer sites are > secure without internet access, simply downloading things via the installer > does not work. This may simply be because libraries that included some of > this stuff are now simply switching to PEAR instead. can you provide some example? -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #40420 — Lukas Kahwe Smith — 2008-09-09T21:26:35+00:00 URL: https://externals.io/message/40391#40420 · In reply to: #40394 Hi, So let me get this straight, you are complaining that all the new features and changes in the 5.3.0 alpha releases are not perfectly documented yet? If that is the case I really wonder how you managed to survive the releases before? Let me just give you a break down of how much better the situation for 5.3.0 is compared to 5.2.0 due to the combined efforts of various teams inside PHP.net: 1) there is a scratchpad that at least lists relevant changes 2) most of the big new features (and some of the small) have RFC's detailing the implementation, the concepts and some examples 3) several features have already been documented (although I guess this was also the case with previous PHP releases, so this does not really count as an improvement .. but like in previous releases as features are tweaked the documentation can get out of sync) 4) we have planned to work on the upgrading guide starting with the beta phase, previously this happened in the RC phase IIRC 5) from my perception new features tend to come in with more test cases than in the past (though i might be mistaken here, but our test coverage is improving even as we add new features) 6) todo list with links to relevant threads, sites, RFC etc (in the past there were much fewer links next to todo items) 7) with alpha2 we even had windows releases at the same time as *nix So yes, this means that for alpha releases, we are not spoon feeding testers. This we are aware of and given the current ressources I think we are in _very_ good shape in 5.3.0 (see above for details). We expect testers to be able and willing to figure things out by reading RFCs, reading test cases, following links on the todo list, checking the scratchpad, checking the documentation, being able to deal with slightly outdated information etc. For the beta phase we want to be able to provide a alpha quality (meaning most things should be mentioned, but some things might not be complete) upgrading guide. So starting with the beta releases, the expectations we have in the testers are lowered significantly. One we are in RC phase, the upgrading guide should be in beta state and I expect the documentation to pick up outdated information and fill in blanks. Though I am not involved enough in the doc team to really tell how they operate and how quickly they can fill in the blanks with the ressources they have. So all in all, it seems to me like you are suffering from unreasonable expectations. Instead you should be congratulating the entire PHP.net crew for their gigantic leap forward. regards, Lukas PS: As for PEAR I agree with Greg. Its not a topic for this list, but suffice it to say that dependency handling is probably one of the strongest points of PEAR. --- ## #40424 — Lester Caine — 2008-09-10T06:43:18+00:00 URL: https://externals.io/message/40391#40424 · In reply to: #40413 Alexey Zakhlestin wrote: > > > […] > > can you provide some example? For example - a bad one since these are pulled in by the project, but it is what I have currently documented. The crib sheet http://www.bitweaver.org/wiki/Version2.1+Windows+niggles was needed to help get new users working, where previous installs simply worked from the zip. http://www.bitweaver.org/downloads/file/11619?highlight=PEAR works with PHP5.2.6 but gives errors on 5.3.0 Those errors now need to be isolated between the core code and the PEAR and other libraries. It takes some time to test every possible path in a full bitweaver install :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #40425 — Lester Caine — 2008-09-10T07:13:55+00:00 URL: https://externals.io/message/40391#40425 · In reply to: #40420 Lukas Kahwe Smith wrote: > Hi, > > So let me get this straight, you are complaining that all the new > features and changes in the 5.3.0 alpha releases are not perfectly > documented yet? PLEASE re-read the original post. If my comments and QUESTIONS are taken as complaints then OK. That is not what was intended. searching on 'namespace' was not giving me anything - I did not think to try 'namespaces' - goto has not got any notes yet? - I've not even looked at phar as it's not on the list I gave the link for so I assume it's still an optional PECL package ... The 'complaint' that I have is that the changes being introduced DO seem to be bringing in problems which when corrected for 5.3 then cause other problems for previous versions of PHP. As an example, the bitweaver framework currently runs out of the box on PHP4 and PHP5. RUNNING it on PHP5.3 gives various warnings and errors that handling for 5.3 then messes up previous versions although WHEN migration is documented there may be options provided that solve those problems? ( And PEAR comes into this equation since potentially we may have to take care of pre and post 5.3 situations? ) Hanging fixes through the code with 'version selects' has not been necessary much up to now but 5.3 seems to be heading that way? We are currently working through the bitweaver 2.1 testing, on 5.2.6 and below so have not yet had time to do any more than checking the code runs on 5.3. The list of things to be looked at on 5.3 was growing so has had to be shelved until the next bitweaver release is out. One has to allocate time productively and BW is currently paying the mortgage for me! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #40427 — Lukas Kahwe Smith — 2008-09-10T07:28:42+00:00 URL: https://externals.io/message/40391#40427 · In reply to: #40425 > Lukas Kahwe Smith wrote: > > […] > > PLEASE re-read the original post. > If my comments and QUESTIONS are taken as complaints then OK. That > is not what was intended. I am pretty sure I read that you complained that information is scattered or unavailable. If I misunderstood you I am sorry. > The 'complaint' that I have is that the changes being introduced DO > seem to be bringing in problems which when corrected for 5.3 then > cause other problems for previous versions of PHP. As an example, > the bitweaver framework currently runs out of the box on PHP4 and > PHP5. RUNNING it on PHP5.3 gives various warnings and errors that > handling for 5.3 then messes up previous versions although WHEN > migration is documented there may be options provided that solve > those problems? > ( And PEAR comes into this equation since potentially we may have to > take care of pre and post 5.3 situations? ) > Hanging fixes through the code with 'version selects' has not been > necessary much up to now but 5.3 seems to be heading that way? We > are currently working through the bitweaver 2.1 testing, on 5.2.6 > and below so have not yet had time to do any more than checking the > code runs on 5.3. The list of things to be looked at on 5.3 was > growing so has had to be shelved until the next bitweaver release is > out. One has to allocate time productively and BW is currently > paying the mortgage for me! Obviously the goal is to minimize BC issues as much as possible. Actually there has to be really sound reason to break BC. So whenever you discover a BC issue that is not noted on the scratchpad please make us aware of this by opening a bug report or by sending a mail to this list. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #40428 — David Coallier — 2008-09-10T07:34:45+00:00 URL: https://externals.io/message/40391#40428 · In reply to: #40425 2008/9/10 Lester Caine : > Lukas Kahwe Smith wrote: > > […] > > PLEASE re-read the original post. > If my comments and QUESTIONS are taken as complaints then OK. That is not > what was intended. > searching on 'namespace' was not giving me anything - I did not think to try > 'namespaces' - goto has not got any notes yet? - I've not even looked at > phar as it's not on the list I gave the link for so I assume it's still an > optional PECL package ... > > The 'complaint' that I have is that the changes being introduced DO seem to > be bringing in problems which when corrected for 5.3 then cause other > problems for previous versions of PHP. As an example, the bitweaver > framework currently runs out of the box on PHP4 and PHP5. RUNNING it on > PHP5.3 gives various warnings and errors that handling for 5.3 then messes > up previous versions although WHEN migration is documented there may be > options provided that solve those problems? > ( And PEAR comes into this equation since potentially we may have to take > care of pre and post 5.3 situations? ) > Hanging fixes through the code with 'version selects' has not been necessary > much up to now but 5.3 seems to be heading that way? We are currently > working through the bitweaver 2.1 testing, on 5.2.6 and below so have not > yet had time to do any more than checking the code runs on 5.3. The list of > things to be looked at on 5.3 was growing so has had to be shelved until the > next bitweaver release is out. One has to allocate time productively and BW > is currently paying the mortgage for me! > Lester, if you have more complaints or suggestions regarding PEAR, I would like to ask you to go on pear-dev. We'll be happy to help you resolve the situations or work something out. Many developers there are running 5.3 as testers and we have had all the problems. Thank you very much, -- Slan, David --- ## #40442 — Marcus Boerger — 2008-09-10T16:44:21+00:00 URL: https://externals.io/message/40391#40442 · In reply to: #40391 Hello Lester, Tuesday, September 9, 2008, 6:05:38 AM, you wrote: > While I have loaded 5.3.? changing any of my existing code base to remove > warnings is not likely to happen any time soon since compatibility with users > who are still running older versions of PHP still needs to be maintained. > I've got http://wiki.php.net/doc/scratchpad/upgrade/53 which seems to be > currently the only reference to changes? But where do I find the detail on how > things ARE currently implemented such as namespace and (fingers down throat) > goto? > Another major concern here since maintaining BC with *PHP4* is still an > unfortunate current requirement in the field is what happens when PEAR > actually uses namespace and other 5.3 only features. HOW will we manage > accessing versions of PEAR that are compatible with our active codebase and so > ensure that we have compatible sets of packages? PHP 4 is no longer supported - in no way. If PEAR still insists on PHP 4 then we cannot support PEAR either. Anyway, as far as I know PEAR does a good job in maintenance, especially in supporting both PHP 4 and 5. And some people are working on a new system that supports PHP 5. marcus > Personally I can't stand the CURRENT problems that is caused by not knowing > which version of a PEAR extension users actually have and in order to ensure a > COMPATIBLE version, but in future will the PEAR installer pick up a correct > version for the copy of PHP actually being run? > I get the distinct impression that those pushing for PHP5.3 are simply not > making a good case for many of us to even want to follow them down that path? > It almost feels like this is a DIFFERENT path to the main stream of PHP6 which > many of us are much more desperate to be testing in the field, which seems to > have become an ignored backwater? Key elements which have been flagged to PHP6 > ( such as BIGINT ) are on hold while new concepts which were not part of the > PHP6 reoadmap have been forced through? Since current hardware *IS* 64 bit, > actually handling 64 bit numbers properly would be nice :) > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/lsces/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php Best regards, Marcus --- ## #40443 — Lester Caine — 2008-09-10T17:43:25+00:00 URL: https://externals.io/message/40391#40443 · In reply to: #40442 Marcus Boerger wrote: > Hello Lester, > > […] > > PHP 4 is no longer supported - in no way. If PEAR still insists on PHP 4 > then we cannot support PEAR either. Anyway, as far as I know PEAR does a > good job in maintenance, especially in supporting both PHP 4 and 5. And > some people are working on a new system that supports PHP 5. Marcus - I've never USED PHP4 in production, but it will be some time before it has been replaced on a lot of ISP's so at present OUR users require maintaining support for PHP on the only versions they have available - at present. NOW it at least practical to freeze a version that supports PHP4 and all the 'extras' that are compatible with that version and not allow any new features to be included in that build. SO we do not have to test changes to the code base for PHP5.3 against PHP4. There have always been problems with using 'new' features but making them available to older versions, which the compatibility libraries provide, but it is looking as if 'Built for PHP5.3' will mean 'will not work on PHP5.2' much more so than previous 'minor version changes'? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #40462 — Marcus Boerger — 2008-09-11T09:58:21+00:00 URL: https://externals.io/message/40391#40462 · In reply to: #40443 Hello Lester, Wednesday, September 10, 2008, 7:43:25 PM, you wrote: > Marcus Boerger wrote: > > […] > Marcus - I've never USED PHP4 in production, but it will be some time before > it has been replaced on a lot of ISP's so at present OUR users require > maintaining support for PHP on the only versions they have available - at > present. NOW it at least practical to freeze a version that supports PHP4 and > all the 'extras' that are compatible with that version and not allow any new > features to be included in that build. SO we do not have to test changes to > the code base for PHP5.3 against PHP4. There have always been problems with > using 'new' features but making them available to older versions, which the > compatibility libraries provide, but it is looking as if 'Built for PHP5.3' > will mean 'will not work on PHP5.2' much more so than previous 'minor version > changes'? Seems like we're on the same track that PHP 4 stays as it is and code that was designed for it can be happily maintained for it as well. So we're at discussing changes inbetween the 5 series. Practically I do not at all care for 5.0 or 5.1, they were experiements. However the move from 5.2 to 5.3 should be as easy as possible. If we have to many BC breaks there then we need to list them all and discuss them one after the other. marcus > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/lsces/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php Best regards, Marcus