several PHP versions will be maintained for 10 years by third-party vendors. PHP5.6 will meet the 10 year mark by 28 august 2024, and freexian.com maintains PHP5.6 with multiple customers paying 6000€/year for 5.6 maintenance. Canonical intends to maintain PHP7.0 until April 2026 for their Ubuntu Pro 16.04. Canonical intends to maintain PHP7.2 until April 2028 for their Ubuntu Pro 18.04. Canonical intends to maintain PHP7.4 until April 2030 for their Ubuntu Pro 20.04. Canonical intends to maintain PHP8.1 until April 2032 for their Ubuntu Pro 22.04.
Red Hat does something similar for their RHEL customers. ~~ On Mon, 10 Apr 2023 at 20:30, Deleu <deleu...@gmail.com> wrote: > > On Mon, Apr 10, 2023, 1:17 PM Pierre Joye <pierre....@gmail.com> wrote: > > > hello, > > > > > > On Sun, Apr 9, 2023, 1:37 AM Stephan Soller <stephan.sol...@helionweb.de> > > wrote: > > > > > Hello, > > > > > > I'm sorry if this isn't the correct mailing list for that discussion but > > I > > > couldn't find a more appropriate one where people actually know how the > > > wind is > > > blowing. > > > > > > A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of > > > deprecations and fatal errors spooked me a bit (details below if you're > > > interested). That got me wondering about the long-term stability of PHP > > > (as in > > > language and API breaks) and I looked at the RFCs. I got the impression > > > that > > > static typing has a lot of traction now and I have no idea of what the > > > fallout > > > might be of changing a dynamically typed language into a statically > > > typed one. > > > > > > I keep reading this in multiple languages, pr even more frameworks. > > > > I understand agency work, managers pushing new features instead of a > > cleaning some legacy. > > > > however years of ignoring deprecation notices (very few were introduced > > right before 8.0). > > > > Most of them could have been fixed within a couple of hours in any code > > base, if they had tests. > > > > I would suggest, very very nicely, to review and rethink the development > > flows of these projects instead of asking php to freeze. > > > > best, > > Pierre > > > > I resent the sentiment of "if your code or development process was exactly > like mine you wouldn't be here complaining" and I believe nobody is asking > PHP to freeze. Not everyone has the ability to fix every deprecation within > a couple of hours and not everyone has tests. Yes, we get it, it's common > knowledge nowadays that code without test is unmanageable, but if you > inherited a 15 year old codebase developed by multiple developers in a > start-up mentality producing code faster than they could actually plan for > and with no tests, its going to take some time to clean that up and if I > take longer than you would, does it mean I matter less as a PHP user? > > PHP 8 is pretty great to work with and a lot better than previous versions, > but there was no opt-in aspect to a lot of PHP breakages. All that we're > asking here is for a bit more forgiveness to existing code that was > developed 2 decades ago by a complete different generation and still need > to run today while we clean it up. > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
