Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104799
Message-ID: <1553002298.18636.11.camel@schlueters.de>
To: David Zuelke <dzuelke@salesforce.com>, PHP internals
	 <internals@lists.php.net>
Date: Tue, 19 Mar 2019 14:31:38 +0100
In-Reply-To: <CAAKq5pr6uxYj5aHKVhqOBAw1dk=kOCb+DWf_qceL_WH+fvNO_g@mail.gmail.com>
References: 
	<CAAKq5pr6uxYj5aHKVhqOBAw1dk=kOCb+DWf_qceL_WH+fvNO_g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] PHP_VERSION_SERIES_EOL_DATE or similar constants?
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

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)