Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104794
MIME-Version: 1.0
References: <CAAKq5pr6uxYj5aHKVhqOBAw1dk=kOCb+DWf_qceL_WH+fvNO_g@mail.gmail.com>
In-Reply-To: <CAAKq5pr6uxYj5aHKVhqOBAw1dk=kOCb+DWf_qceL_WH+fvNO_g@mail.gmail.com>
Date: Tue, 19 Mar 2019 09:29:24 +0100
Message-ID: <CAF+90c_EW1-P33g0D4_f3O2RYZVvV+xucwDmBQgBAAVhVhD+BA@mail.gmail.com>
To: David Zuelke <dzuelke@salesforce.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006751ef05846e4ec1"
Subject: Re: [PHP-DEV] PHP_VERSION_SERIES_EOL_DATE or similar constants?
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000006751ef05846e4ec1
Content-Type: text/plain; charset="UTF-8"

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...

Nikita

--0000000000006751ef05846e4ec1--