Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89755
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.213.51 as permitted sender)
References: <0a0a70d756b14a84fc1cd19fd04bb914@mail.gmail.com> <C7F52D0F-7169-48D0-B0AC-9D755205E21B@heroku.com>
In-Reply-To: <C7F52D0F-7169-48D0-B0AC-9D755205E21B@heroku.com>
MIME-Version: 1.0
Thread-Index: AQH9h+SVbTPP/WEeB2e7emvDvziBxQNGBcpTnk5YPzA=
Date: Tue, 8 Dec 2015 17:27:11 +0200
Message-ID: <50da87b3e7233d2b204d16e61092fe88@mail.gmail.com>
To: David Zuelke <dz@heroku.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] RFC: PHP 5.6 Support Timeline
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: David Zuelke [mailto:dz@heroku.com]
> Sent: Tuesday, December 08, 2015 5:19 PM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] RFC: PHP 5.6 Support Timeline
>
> It just occurred to me (too late :D sorry Zeev) that it might make sense
> to
> split this into two RFCs:
>
> - to define the active support end date for 5.6 (e.g. "2016-08-28" or
> "2016-
> 12-02" or "2016-12-31")
> - to define the security support end date for 5.6, and specify that
> relative to
> the active support end date only (e.g. "12 months after active support end
> date" or "24 months after active support end date")
>
> That would also allow us to, if the need arises, change the active support
> end date sometime next year (for whatever reason; let's hope it is not
> necessary!) without having to open up a discussion about the security end
> date again ;)

I think we can do it within the framework of a single RFC - simply make it
clearer in the RFC text that the Security Support term begins when the
Active Support term ends.  That way if we want to change the Active Support
term in the future (with another RFC), it won't alter the Security Support
term we agree on here, unless that future RFC explicitly deals with changing
the Security Support term as well.

Makes sense?

Zeev

P.S.:  I really hope we can come to a final conclusion as a result of this
RFC, and not have to change it in the future.  That's another reason why 1+2
years makes sense - it's far enough in the future to give mostly everyone
enough time to migrate on their own terms, and equally important, for us to
be able to say this publicly, as in "People, we're giving you enough time -
there won't be any additional extensions, plan your migration accordingly".