Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104798
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> <CAEZPtU63qBGgq5NGnxmXKZDZ31F=K5NPSk-7prs_zGsmWARBsg@mail.gmail.com>
In-Reply-To: <CAEZPtU63qBGgq5NGnxmXKZDZ31F=K5NPSk-7prs_zGsmWARBsg@mail.gmail.com>
Date: Tue, 19 Mar 2019 12:00:07 +0100
Message-ID: <CADyq6s+-sRL=Ks=rsdNVoY30eGAhVyr0+3ZJ-9xENzfw2t4eUA@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, David Zuelke <dzuelke@salesforce.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002bd9b10584706907"
Subject: Re: [PHP-DEV] PHP_VERSION_SERIES_EOL_DATE or similar constants?
From: ocramius@gmail.com (Marco Pivetta)

--0000000000002bd9b10584706907
Content-Type: text/plain; charset="UTF-8"

On Tue, Mar 19, 2019 at 11:59 AM Pierre Joye <pierre.php@gmail.com> wrote:

> 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. :)
>

Stop giving me ideas!

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--0000000000002bd9b10584706907--