Re: [RFC] Release cycle update, take #2
| From: | Derick Rethans | 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