Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122717
Message-ID: <680bfd62-cddb-4f7c-8adb-d1c84a51cffb@varteg.nz>
Date: Fri, 22 Mar 2024 09:34:18 +1300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Release cycle update, take #2
Content-Language: en-GB
To: internals@lists.php.net
References: <CAEKnhAHs-8aQwy89=xwgiLZzn=d8DKid9-S4m95jkNzxO0hARQ@mail.gmail.com>
 <04736cc6-0372-8228-7d2a-7e12453a8f0c@php.net>
 <45598d80-7834-4355-9b30-b5da99a611f4@app.fastmail.com>
In-Reply-To: <45598d80-7834-4355-9b30-b5da99a611f4@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: Weedpacket@varteg.nz (Morgan)

On 2024-03-22 08:19, Jim Winstead wrote:
> On Thu, Mar 21, 2024, at 10:54 AM, Derick Rethans wrote:
>>
>> The RFC is at https://wiki.php.net/rfc/release_cycle_update
> 
> Could this RFC also be a good time to clarify what sort of BC changes are actually allowed in major and minor releases, or should we save that for a different RFC? (Because it's already been acknowledged that the current written policy doesn't align with the practiced policy, and I think it would be nice to get those in sync.)
> 
If so, would it also good time/place to clarify how deprecation relates 
to future removal. Say, while deprecations could come in any minor 
release, they would be removed only after a full major version has 
elapsed (something deprecated in 8.x would be removed in 10.0; 
technically that would mean a deprecation in 9.0.0 would also mean 
removal in 10.0). It would allow using the overall release cycle to 
forecast when something you're currently relying on will go away and 
plan accordingly.