On Mo, 2019-03-18 at 23:30 +0100, David Zuelke wrote: > > It would be really useful for e.g. code check systems, tools like > Composer, hosting platforms, to inform the user of an upcoming or > past > EOM/EOL date, without having to maintain a list of these dates > separately (by copying from, or scraping, php.net/eol.php).
Scraping isn't needed. We have http://php.net/releases/active.php which gives current versions as JSON and it should be trivial to extend that with EOL dates. Hard-coding this in a release imo is not a good idea since we might change our minds. Imagine we figure out that 9.3.0 contained a completely broken implementation of a feature, which we can only fix in a breaking 10.0.0 release. Then we might decide to break our policy and kill of 9.3 quickly and do a 10.0 sooner. Or we might see that 42.0.0 is a big break and people are stuck with 41.23.0 as all major applications have issue with the break. Then we could decide to extend lifetime a bit, while 42.4.0 will bring a change easing the transition. Making predictions about the future is hard. Telling our intention to our users, like on http://php.net/supported-versions.php is good but we should always have the liberty to change our minds. Hard-coding a date in the distributed source takes away that liberty. johannes P.S. I am NOT saying we should break those expectations we set out and the examples are completely artificial. (and I still believe we shouldn't have so many parallel branches, but go for a LTS+early access model instead, but that's a very independent discussion) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
