Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104797
MIME-Version: 1.0
References: <CAAKq5pr6uxYj5aHKVhqOBAw1dk=kOCb+DWf_qceL_WH+fvNO_g@mail.gmail.com>
 <CAF+90c_EW1-P33g0D4_f3O2RYZVvV+xucwDmBQgBAAVhVhD+BA@mail.gmail.com>
In-Reply-To: <CAF+90c_EW1-P33g0D4_f3O2RYZVvV+xucwDmBQgBAAVhVhD+BA@mail.gmail.com>
Date: Tue, 19 Mar 2019 17:58:56 +0700
Message-ID: <CAEZPtU63qBGgq5NGnxmXKZDZ31F=K5NPSk-7prs_zGsmWARBsg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: David Zuelke <dzuelke@salesforce.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000fc0c690584706461"
Subject: Re: [PHP-DEV] PHP_VERSION_SERIES_EOL_DATE or similar constants?
From: pierre.php@gmail.com (Pierre Joye)

--000000000000fc0c690584706461
Content-Type: text/plain; charset="UTF-8"

On Tue, Mar 19, 2019, 3:29 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Mon, Mar 18, 2019 at 11:31 PM David Zuelke <dzuelke@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. :)


> Nikita
>

--000000000000fc0c690584706461--