On Tue, Mar 19, 2019 at 11:59 AM Pierre Joye <pierre....@gmail.com> wrote:
> On Tue, Mar 19, 2019, 3:29 PM Nikita Popov <nikita....@gmail.com> wrote: > > > 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... > > > > 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/
