# PHP_VERSION_SERIES_EOL_DATE or similar constants? - Thread: https://externals.io/message/104790 - Original archive: https://news-web.php.net/php.internals/104790 - Started by David Zuelke on 2019-03-18T22:30:45+00:00 - Messages: 6 - 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 --- ## #104790 — David Zuelke — 2019-03-18T22:30:45+00:00 URL: https://externals.io/message/104790#104790 Hi all, Would it not be lovely to have, say, two new constants, that contain the date (ISO, UTC, I guess) of when the running PHP series will be end-of-maintenance and end-of-life? Of course PHP_VERSION_SERIES_EOM_DATE and PHP_VERSION_SERIES_EOL_DATE are a little verbose, but... 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). Does that sound useful to anyone? It would of course be problematic in cases where the EOL date is yet to be determined, or changes later (as it happened with the 5.6 extension), but given that there would still be newer releases after such a case, where the value of the constant(s) could then be updated, that'd probably not be so problematic. Trivial? Not? Great? Bad? RFC worthy? Regards, David --- ## #104792 — Stanislav Malyshev — 2019-03-19T00:20:32+00:00 URL: https://externals.io/message/104790#104792 Hi! > 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). Why not create a composer package on packagist.org with those if there's a need to share them in common machine-readable form? -- Stas Malyshev smalyshev@gmail.com --- ## #104794 — Nikita Popov — 2019-03-19T08:29:24+00:00 URL: https://externals.io/message/104790#104794 On Mon, Mar 18, 2019 at 11:31 PM David Zuelke wrote: > Hi all, > > Would it not be lovely to have, say, two new constants, that contain > the date (ISO, UTC, I guess) of when the running PHP series will be > end-of-maintenance and end-of-life? > > Of course PHP_VERSION_SERIES_EOM_DATE and PHP_VERSION_SERIES_EOL_DATE > are a little verbose, but... > > 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). > > Does that sound useful to anyone? It would of course be problematic in > cases where the EOL date is yet to be determined, or changes later (as > it happened with the 5.6 extension), but given that there would still > be newer releases after such a case, where the value of the > constant(s) could then be updated, that'd probably not be so > problematic. > > Trivial? Not? Great? Bad? RFC worthy? > The concept seems useful, but I don't think that including these as constants as part of the PHP build is practical. As you already mentioned, we may decide to extend the lifecycle of a PHP version after it has been released. Even if we don't, the end-of-life dates are more like fuzzy targets than hard deadlines. Depending on release schedule and pending patches, the last release may fall something like +/- one month around the EOL date. To add to that you have the issue of distro support. Many people use PHP binaries from LTS distros, which provide security support beyond PHP's own support lifecycle. I don't think it would be useful to try and get that information into PHP builds. Stas suggestion of a composer package with the necessary data seems much more practical... Nikita --- ## #104797 — Pierre Joye — 2019-03-19T10:58:56+00:00 URL: https://externals.io/message/104790#104797 > On Mon, Mar 18, 2019 at 11:31 PM David Zuelke > wrote: > > > […] > > The concept seems useful, but I don't think that including these as > constants as part of the PHP build is practical. As you already mentioned, > we may decide to extend the lifecycle of a PHP version after it has been > released. Even if we don't, the end-of-life dates are more like fuzzy > targets than hard deadlines. Depending on release schedule and pending > patches, the last release may fall something like +/- one month around the > EOL date. > > To add to that you have the issue of distro support. Many people use PHP > binaries from LTS distros, which provide security support beyond PHP's own > support lifecycle. > > I don't think it would be useful to try and get that information into PHP > builds. Stas suggestion of a composer package with the necessary data seems > much more practical... > I can already see bugs report from packages refusing to work if the date is already past. :) > Nikita --- ## #104798 — Marco Pivetta — 2019-03-19T11:00:07+00:00 URL: https://externals.io/message/104790#104798 > > > > […] > mentioned, > > […] > the > > […] > own > > […] > seems > > […] > > I can already see bugs report from packages refusing to work if the date is > already past. :) > Stop giving me ideas! Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #104799 — johannes@schlueters.de — 2019-03-19T13:31:38+00:00 URL: https://externals.io/message/104790#104799 >  > 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)