Re: [RFC] Release cycle update, take #2

From: Date: Fri, 29 Mar 2024 16:34:05 +0000
Subject: Re: [RFC] Release cycle update, take #2
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-122808@lists.php.net to get a copy of this message
On Fri, 22 Mar 2024, Morgan wrote: > 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. The current "rule" is that we can remove deprecated features in any x.0.0 release (https://github.com/php/policies/blob/main/release-process.rst#releases-cycle). I am not proposing to change that with this RFC. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social

« previous php.internals (#122808) next »