Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » PHP_VERSION_SERIES_EOL_DATE or similar constants? »

PHP_VERSION_SERIES_EOL_DATE or similar constants?

php.internals

David Zuelke

7 years ago
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? Regards, David

Stas Malyshev

7 years ago
Hi!
> 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).
Why not create a composer package on packagist.org with those if there's a need to share them in common machine-readable form?
-- Stas Malyshev smalyshev@gmail.com

Nikita Popov

7 years ago
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

Pierre Joye

7 years ago
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. :)

Marco Pivetta

7 years ago
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/

Johannes Schlueter

7 years ago
On Mo, 2019-03-18 at 23:30 +0100, David Zuelke wrote:
>  > 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).
Scraping isn't needed. We have http://php.net/releases/active.php which gives current versions as JSON and it should be trivial to extend that with EOL dates. Hard-coding this in a release imo is not a good idea since we might change our minds. Imagine we figure out that 9.3.0 contained a completely broken implementation of a feature, which we can only fix in a breaking 10.0.0 release. Then we might decide to break our policy and kill of 9.3 quickly and do a 10.0 sooner. Or we might see that 42.0.0 is a big break and people are stuck with 41.23.0 as all major applications have issue with the break. Then we could decide to extend lifetime a bit, while 42.4.0 will bring a change easing the transition. Making predictions about the future is hard. Telling our intention to our users, like on http://php.net/supported-versions.php is good but we should always have the liberty to change our minds.  Hard-coding a date in the distributed source takes away that liberty. johannes P.S. I am NOT saying we should break those expectations we set out and the examples are completely artificial. (and I still believe we shouldn't have so many parallel branches, but go for a LTS+early access model instead, but that's a very independent discussion)