PHP_VERSION_SERIES_EOL_DATE or similar constants?

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

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

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

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

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/

 
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)