# 5.5 to 5.6 cleanup - Thread: https://externals.io/message/71218 - Original archive: https://news-web.php.net/php.internals/71218 - Started by Julien Pauli on 2014-01-17T23:07:40+00:00 - Messages: 19 - 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 --- ## #71218 — Julien Pauli — 2014-01-17T23:07:40+00:00 URL: https://externals.io/message/71218#71218 Hi all, In 5.5, we deprecated some things : - /e for preg - ext/mysql - ext/intl stuff I recall that based on our release process, those items should now get removed from 5.6 code for final release. I guess this can be done in one commit, except perhaps for ext/mysql that has to be moved to pecl. Thoughts ? Julien Pauli --- ## #71220 — Andrea Faulds — 2014-01-18T00:24:16+00:00 URL: https://externals.io/message/71218#71220 · In reply to: #71218 > - ext/mysql I have little care for those other things. However, there is a massive amount of mysql_* code (sadly, some of it written recently) out there. Is it really a good idea to remove it now? Then again, I suppose it has to be done some day. If it's moved to PECL, distribution maintainers could include the PECL package. So I guess I'm not entirely against it, but I'd recommend caution here. -- Andrea Faulds http://ajf.me/ --- ## #71221 — Yasuo Ohgaki — 2014-01-18T00:32:03+00:00 URL: https://externals.io/message/71218#71221 · In reply to: #71220 Hi all, > > > > […] > > I have little care for those other things. However, there is a massive > amount of mysql_* code (sadly, some of it written recently) out there. Is > it really a good idea to remove it now? > > Then again, I suppose it has to be done some day. If it's moved to PECL, > distribution maintainers could include the PECL package. > > So I guess I'm not entirely against it, but I'd recommend caution here. > I agree. IIRC, WordPress 3.8 still uses mysql. Moving mysql to PECL is mandatory. IMHO. Intl is better to be moved to PECL also. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #71222 — Sherif Ramadan — 2014-01-18T00:53:58+00:00 URL: https://externals.io/message/71218#71222 · In reply to: #71218 > Hi all, > > In 5.5, we deprecated some things : > - /e for preg > - ext/mysql > - ext/intl stuff > > I recall that based on our release process, those items should now get > removed from 5.6 code for final release. > > I guess this can be done in one commit, except perhaps for ext/mysql > that has to be moved to pecl. > > Thoughts ? > To be fair, the RFC we voted on for ext/mysql was strictly for whether or not we should use `E_DEPRECATED` errors in 5.5. https://wiki.php.net/rfc/mysql_deprecation That was the accepted RFC. We never voted on whether or not it should be removed from 5.6. In fact, that was what caused a lot of the confusion about that RFC to begin with. People were afraid we were going to remove it in 5.5. --- ## #71223 — Yasuo Ohgaki — 2014-01-18T01:22:37+00:00 URL: https://externals.io/message/71218#71223 · In reply to: #71222 Hi all, On Sat, Jan 18, 2014 at 9:53 AM, Sherif Ramadan wrote: > > […] > > > To be fair, the RFC we voted on for ext/mysql was strictly for whether or > not we should use `E_DEPRECATED` errors in 5.5. > > https://wiki.php.net/rfc/mysql_deprecation > > That was the accepted RFC. We never voted on whether or not it should be > removed from 5.6. In fact, that was what > caused a lot of the confusion about that RFC to begin with. People were > afraid we were going to remove it in 5.5. We may better to have standard schedule for deprecated feature. Release process RFC does not describe it. https://wiki.php.net/rfc/releaseprocess For modules, users may get code from PECL so it does not matter much, though. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #71224 — Arvids Godjuks — 2014-01-18T01:35:26+00:00 URL: https://externals.io/message/71218#71224 · In reply to: #71218 18 янв. 2014 г. 1:08 пользователь "Julien Pauli" написал: > > Hi all, > > In 5.5, we deprecated some things : > - /e for preg > - ext/mysql > - ext/intl stuff > > I recall that based on our release process, those items should now get > removed from 5.6 code for final release. > > I guess this can be done in one commit, except perhaps for ext/mysql > that has to be moved to pecl. > > Thoughts ? > > > Julien Pauli > > -- > > > As it was mentioned, it was not decided that mysql ext should be completly removed at 5.6, my personal opinion is that it should be pushed po PECL at this release with all the bells and whistells warning everyone that extension is depricated and will be removed soon (read: next release - be it 5.7 or 6.0). I belive that leaving everything as is right now will be sending a message that projects like Wordpress can halt the progress of the language development and block the decisions like removal of the mysql ext. But thats for the sake of the slowpokes that still didn't adopt the mysqli (moving from mysql to mysqli is not really that hard...) or moved to PDO. As far as i'm concered personaly, mysql ext died a long ago for me (was using mysqli since first stable releases). My 0.02$ P.S. For gods sakes, did I just saw someone still writing code based on mysql ext while it is marked as depricated? It is known for years now that it is being nuked - frankly I'm surprised it wasn't deleted a long time ago. --- ## #71225 — Andrea Faulds — 2014-01-18T01:38:48+00:00 URL: https://externals.io/message/71218#71225 · In reply to: #71224 > P.S. For gods sakes, did I just saw someone still writing code based on > mysql ext while it is marked as depricated? It is known for years now that > it is being nuked - frankly I'm surprised it wasn't deleted a long time ago. You see it all the time, in good part because of awful PHP tutorials which promote outdated methods. -- Andrea Faulds http://ajf.me/ --- ## #71226 — Arvids Godjuks — 2014-01-18T01:51:22+00:00 URL: https://externals.io/message/71218#71226 · In reply to: #71225 18 янв. 2014 г. 3:38 пользователь "Andrea Faulds" написал: > > > > > > […] that > > […] ago. > > > You see it all the time, in good part because of awful PHP tutorials which promote outdated methods. > > > -- > Andrea Faulds > http://ajf.me/ Tutorials or not, there is so much outdated crap on the internet now, that any decent human being is able to filter it out. Old tutorials are not an excuse anymore. I belive that we are at the point, where anyone who is still sitting on old libraries like mysql ext, is personaly responsible for his own actions and can blame only himself. The PHP development has streamlined a lot in last 2 years and part of that process is finally getting rid of old stuff. --- ## #71227 — Sherif Ramadan — 2014-01-18T01:55:38+00:00 URL: https://externals.io/message/71218#71227 · In reply to: #71224 On Fri, Jan 17, 2014 at 8:35 PM, Arvids Godjuks wrote: > > As it was mentioned, it was not decided that mysql ext should be completly > removed at 5.6, my personal opinion is that it should be pushed po PECL at > this release with all the bells and whistells warning everyone that > extension is depricated and will be removed soon (read: next release - be > it 5.7 or 6.0). The plan was always to move ext/mysql to PECL. We've never removed an entire extension from the source completely without it going to PECL (as in the case of SQLite). Which is why the decision was made to first update the documentation warning people that ext/mysql would soon be deprecated. Later the decision was made to start issuing `E_DEPRECATED` errors in PHP 5.5, as per the aforementioned RFC that was accepted. This has all been done already. The next step is to remove ext/mysql from PHP core and place into PECL. The various linux distributions will likely still package it separately as they already do with other various PHP extensions. So this will not likely affect those who rely on using their distribution's package manager to install PHP extensions. However, that is not to say that we should spring things upon users suddenly and without taking the necessary steps to ensure a smoother transition. > I belive that leaving everything as is right now will be > sending a message that projects like Wordpress can halt the progress of the > language development and block the decisions like removal of the mysql ext. > > I agree that we should not be waiting on Wordpress to update their code in order to make the decision of removing ext/mysql. In fact, in our previous discussion back in 2012, Wordpress claims they were the ones waiting on us before they updated their code http://news.php.net/php.internals/63929 We've given fair warning that the extension will be removed soon. I'm just saying that the decisions to remove it was never finalized to 5.6. We've ramped-up our release cycles and we've gone from 5.4 to 5.5 to 5.6 in less than 2 years now. --- ## #71228 — Sherif Ramadan — 2014-01-18T01:59:46+00:00 URL: https://externals.io/message/71218#71228 · In reply to: #71227 On Fri, Jan 17, 2014 at 8:55 PM, Sherif Ramadan wrote: > > > In fact, in our previous discussion back in 2012, Wordpress claims they > were the ones waiting on us before they updated their code > http://news.php.net/php.internals/63929 > > Actually that was the wrong link to that thread. I mean to refer to this http://news.php.net/php.internals/63918 --- ## #71229 — Julien Pauli — 2014-01-18T02:19:12+00:00 URL: https://externals.io/message/71218#71229 · In reply to: #71221 > Hi all, > > > > […] > > > I agree. > IIRC, WordPress 3.8 still uses mysql. > > Moving mysql to PECL is mandatory. IMHO. > Intl is better to be moved to PECL also. There is no point in moving ext/intl to PECL. the intl stuff which is deprecated in 5.5 is just few functions, ext/intl stays into PHP. Julien --- ## #71230 — Julien Pauli — 2014-01-18T02:42:10+00:00 URL: https://externals.io/message/71218#71230 · In reply to: #71227 > On Fri, Jan 17, 2014 at 8:35 PM, Arvids Godjuks wrote: > > > […] > > > The plan was always to move ext/mysql to PECL. We've never removed an > entire extension from the source completely without it going to PECL (as in > the case of SQLite). For sure, we don't delete code from our codebase. We don't drop ext/mysql code , we clearly move it to PECL, yes. > Which is why the decision was made to first update the > documentation warning people that ext/mysql would soon be deprecated. Later > the decision was made to start issuing `E_DEPRECATED` errors in PHP 5.5, as > per the aforementioned RFC that was accepted. This has all been done > already. The next step is to remove ext/mysql from PHP core and place into > PECL. The various linux distributions will likely still package it > separately as they already do with other various PHP extensions. So this > will not likely affect those who rely on using their distribution's package > manager to install PHP extensions. However, that is not to say that we > should spring things upon users suddenly and without taking the necessary > steps to ensure a smoother transition. For me that's clear. - We added `E_DEPRECATED` at runtime - We updated docs to reflect that We'll still provide the code to a PECL ext, and linux distros will package it, so no pain for anyone wanting to use ext/mysql once it's moved to PECL. > > > > […] > I agree that we should not be waiting on Wordpress to update their code in > order to make the decision of removing ext/mysql. In fact, in our previous > discussion back in 2012, Wordpress claims they were the ones waiting on us > before they updated their code http://news.php.net/php.internals/63929 > > We've given fair warning that the extension will be removed soon. I'm just > saying that the decisions to remove it was never finalized to 5.6. We've > ramped-up our release cycles and we've gone from 5.4 to 5.5 to 5.6 in less > than 2 years now. Yes, we don't have to wait for anybody to take actions. We should be driving projects using PHP, not the opposite (which doesn't mean we should not listen to everybody and take selfish decisions). If we go to remove it in 5.6, anyway, we all know there will be a huge time before 5.6 enters to production, years... Also, nobody can miss the deprecation, as nobody jumps over versions while migrating (e.g, moving directly from 5.4 to 5.6). Perhaps is it time to clarify our deprecation process into an RFC we all agree with ? This RFC could describe a clear deprecation process, from INI settings deprecation, classes/functions etc... to entire extensions. As soon as it's clear to everybody and accepted, RMs can do their job blindly following the RFC. Julien.P --- ## #71231 — Yasuo Ohgaki — 2014-01-18T02:43:36+00:00 URL: https://externals.io/message/71218#71231 · In reply to: #71229 Hi Julien, > There is no point in moving ext/intl to PECL. > the intl stuff which is deprecated in 5.5 is just few functions, > ext/intl stays into PHP. > Thank you for the clarification. We defiantly need guideline first for function deprecation. IMHO. Isn't it too fast deprecate function in 5.5 and remove it from 5.6, is it? It might be better keep them at least few releases. Perhaps, +2 releases at least? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net --- ## #71234 — Adam Harvey — 2014-01-18T04:09:03+00:00 URL: https://externals.io/message/71218#71234 · In reply to: #71218 > In 5.5, we deprecated some things : > - /e for preg > - ext/mysql > - ext/intl stuff > > I recall that based on our release process, those items should now get > removed from 5.6 code for final release. I don't think that's specified anywhere — we _can_ choose to remove them in 5.6 if we want to, but that doesn't mean we have to. I deliberately left that open ended for the ext/mysql deprecation, for instance. Personally, I'd be pretty strongly against unbundling ext/mysql in 5.6, as it's still too heavily used. The lag time for new PHP releases to start getting widespread use is long enough that most users haven't even seen a deprecation warning yet. The others: meh. I'm not qualified to judge how used those intl functions are, and while /e is an abomination, nobody new is going to get owned if it survives one more release. Neutral on those. Adam --- ## #71236 — Pierre Joye — 2014-01-18T06:41:46+00:00 URL: https://externals.io/message/71218#71236 · In reply to: #71218 > > Hi all, > > In 5.5, we deprecated some things : > - /e for preg > - ext/mysql > - ext/intl stuff Intl? Are you sure? > I recall that based on our release process, those items should now get > removed from 5.6 code for final release. No, it can be done in the next major version, 6.x. > I guess this can be done in one commit, except perhaps for ext/mysql > that has to be moved to pecl. > > Thoughts ? I really do not think we can remove mysql from core at this stage (or anything else before 6.x). As much as I would love to see users move away from ext/mysql, we have decided to go down the soft way. It sounded and still sound reasonable to me. Cheers, Pierre --- ## #71237 — Ryan McCue — 2014-01-18T10:00:02+00:00 URL: https://externals.io/message/71218#71237 · In reply to: #71228 Sherif Ramadan wrote: > On Fri, Jan 17, 2014 at 8:55 PM, Sherif Ramadan wrote: > > […] > Actually that was the wrong link to that thread. I mean to refer to this > http://news.php.net/php.internals/63918 > To clarify, the point I was making there was that it was low priority for us to change it until PHP deprecated it. The database code in WP forms an important part of architecture that we're loathe to change if not needed. As noted in the current fix [1], we plan to remove the current code which simply hides the deprecated notices and replace the database code with a new mysqli/PDO-based database connector, however we're not done on that yet. [1]: https://core.trac.wordpress.org/changeset/26512 -- Ryan McCue написал: >..... > Also, nobody can miss the deprecation, as nobody jumps over versions while migrating (e.g, moving directly from 5.4 to 5.6). > Julien.P Well, on a side note, I actually jumped from 5.3 to 5.5 completely ignoring 5.4 :) On the overall topic, I mostly agree with what's being said. Move to PECL, depricate and completely remove in 6.0 or wharever it is going to be called. As long as everyone is commited to get rid of this travesty, I have no problem with a softer aproach. --- ## #71242 — Lester Caine — 2014-01-18T13:25:08+00:00 URL: https://externals.io/message/71218#71242 · In reply to: #71238 Arvids Godjuks wrote: > > […] > while migrating (e.g, moving directly from 5.4 to 5.6). > > […] > Well, on a side note, I actually jumped from 5.3 to 5.5 completely ignoring > 5.4:) This is the reality! And the cause of many of the problems. I'm still tied to 5.4 because much of my customer base is still tied to XP/2000 and the move is from PHP5.2 to 5.4. However it would probably have been easier to clean up all the code on 5.3 before then reworking it again for 5.4. The one thing that is still very lacking is a good tutorial on e_strict compliant design. 95% of search results still pull up mysql code and does not provide good examples of 'modern design'. Since many existing users are still reliant on legacy code, it's a good conversion guide which is more important and not something that single version migration guides actually helps with. This is the main reason I'm trying to develop some more complete guides, but I just don't understand why may own perfectly functional code is no longer acceptable much of the time :( It just creates e_strict warnings and errors. -- 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 --- ## #71303 — Stas Malyshev — 2014-01-20T07:54:01+00:00 URL: https://externals.io/message/71218#71303 · In reply to: #71236 Hi! > > […] > > Intl? Are you sure? There's a function that we deprecated in 5.5, namely setTimeZoneID. It was replaced by much better one, setTimeZone. But technically there's no strict necessity really to remove it, except that new code is supposed to always use new function. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227