On Mon, Mar 18, 2019 at 11:31 PM David Zuelke <dzue...@salesforce.com> 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
