>> Why again we must breaking people's working code? > > Something I've been asking for years ;) > > Bigger frameworks still designing for PHP5.3 is happening because 5.2 > code still works on 5.3 by hiding warnings, but fails on 5.4. They are > trying to keep THEIR users functional in the real world, and the real > world is dragging it's feet simply because the majority of users would > not know what E_DEPRECATED means. "They have had plenty of time to fix > this" assumes that the people who wrote the original code are still > around TO fix it? I'm still finding live code that originated in PHP4 > days - using 'mysql_' - and works perfectly - on 5.2. > I have three options now ... > 1/ Stick with a stack that will run their code > 2/ Tell the customers they need to repair all their code > 3/ Charge them for the time to repair the code for them >
Coming from a distribution packaging background, keeping software alive and secure is an ongoing effort. It's not buy and forget. Scripts and frameworks need security and bug fixes, binary code needs to be rebuilt against newer base system libraries, and as compiler versions mature, a lot of code which previously built needs to be fixed even if it's unchanged. There is nothing wrong with that. It's just the way it is. Unmaintained Software will retain unfixed bugs, unfixed security holes and ultimately break because of external changes. the mysql extension maintainers do not want to or cannot support the extension for much longer. It's perfectly ok for them to do so. php internals' task is to run this through their deprecation cycle and educate anybody who is listening how to cope with 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
