[RFC] [Discussion] Release cycle update

Larry Garfield

2 years ago

On Fri, Nov 10, 2023, at 10:51 AM, Jakub Zelenka wrote:

> Hello,
>
> I would like to propose a new process RFC for updates to PHP release cycle:
>
> https://wiki.php.net/rfc/release_cycle_update
>
> This has been discussed between release managers to make sure that all are
> happy as some of the points impact release managers (e.g. longer security
> support).
>
> I also opened a PR to my new personal repo for RFC's if anyone has got any
> suggestion for better wording or notices any typo:
>
> https://github.com/bukka/php-rfc/pull/1
>
> Cheers
>
> Jakub

If the release managers are in favor, I am in favor, generally.  I'm sure the longer security cycle will get cheers from hosting organizations and jeers from package maintainers. :-)

A few questions/comments/observations:

* "Allow feature that do not require RFC in beta" -  The description doesn't quite sound like it's talking about "features."  It's talking about refactoring, bug fixes, edge case handling, etc.  Those are certainly beta-friendly tasks, I agree, but I wouldn't describe those as "features."  The open hole here is that the description also talks about "minor features that don't require an RFC", the threshold for which is... highly fluid.  That's a potential confusion point.

* Reduce number of RC to 4 - I support this!  However, it's not clear if that means we get an extra 2 betas, or an extra month of alpha (where RFCs are allowed).  Personally I would favor the latter, but as written the text is unclear on which is intended.

Including a revised calendar of what happens when under this policy in a table or chart or something would be very helpful.

--Larry Garfield

Jakub Zelenka

2 years ago

Hi,

On Fri, Nov 10, 2023 at 5:20 PM Larry Garfield <larry@garfieldtech.com>
wrote:

>
> * "Allow feature that do not require RFC in beta" -  The description
> doesn't quite sound like it's talking about "features."  It's talking about
> refactoring, bug fixes, edge case handling, etc.  Those are certainly
> beta-friendly tasks, I agree, but I wouldn't describe those as "features."
> The open hole here is that the description also talks about "minor features
> that don't require an RFC", the threshold for which is... highly fluid.
> That's a potential confusion point.
>
>

So there are actually many small features (adding constant, parameters,
config options or even small functions / methods) that are being merged
without RFC to master. In general if there are no objections, such change
is merged. So effectively the proposal is to keep doing that in beta as
well because some bigger features (approved RFCs) can be merged too.

> * Reduce number of RC to 4 - I support this!  However, it's not clear if
> that means we get an extra 2 betas, or an extra month of alpha (where RFCs
> are allowed).  Personally I would favor the latter, but as written the text
> is unclear on which is intended.
>

The proposal is to not introduce any extra alphas or betas and just shorten
the whole pre-release time. Effectively alpha does not have almost any
meaning rather than just announcement and probably more importantly a test
for new RM's how to do a release (that's actually pretty useful from my own
experience) so there is no point to do more than 3 alphas. And beta is
currently more just time to get the RFC implemented but there is
effectively no real feature freeze - ABI is still open for changes and RFC
can be merged as I mentioned above. So not sure if there's much point to
have more than 3.

The text needs probably clarifying so I will update it.

Thanks

Jakub

Larry Garfield

2 years ago

On Fri, Nov 10, 2023, at 2:11 PM, Jakub Zelenka wrote:

> Hi,
>
> On Fri, Nov 10, 2023 at 5:20 PM Larry Garfield <larry@garfieldtech.com>
> wrote:
>
>>
>> * "Allow feature that do not require RFC in beta" -  The description
>> doesn't quite sound like it's talking about "features."  It's talking about
>> refactoring, bug fixes, edge case handling, etc.  Those are certainly
>> beta-friendly tasks, I agree, but I wouldn't describe those as "features."
>> The open hole here is that the description also talks about "minor features
>> that don't require an RFC", the threshold for which is... highly fluid.
>> That's a potential confusion point.
>>
>>
> So there are actually many small features (adding constant, parameters,
> config options or even small functions / methods) that are being merged
> without RFC to master. In general if there are no objections, such change
> is merged. So effectively the proposal is to keep doing that in beta as
> well because some bigger features (approved RFCs) can be merged too.
>
>
>> * Reduce number of RC to 4 - I support this!  However, it's not clear if
>> that means we get an extra 2 betas, or an extra month of alpha (where RFCs
>> are allowed).  Personally I would favor the latter, but as written the text
>> is unclear on which is intended.
>>
>
> The proposal is to not introduce any extra alphas or betas and just shorten
> the whole pre-release time. Effectively alpha does not have almost any
> meaning rather than just announcement and probably more importantly a test
> for new RM's how to do a release (that's actually pretty useful from my own
> experience) so there is no point to do more than 3 alphas. And beta is
> currently more just time to get the RFC implemented but there is
> effectively no real feature freeze - ABI is still open for changes and RFC
> can be merged as I mentioned above. So not sure if there's much point to
> have more than 3.
>
> The text needs probably clarifying so I will update it.

I suppose more to the point, does this mean the deadline for RFCs pushes later?  That seems to be implied, but should be made explicit.

--Larry Garfield

Ilija Tovilo

2 years ago

Hi Jakub

Thank you for the proposal.

On Fri, Nov 10, 2023 at 5:52 PM Jakub Zelenka <bukka@php.net> wrote:

> https://wiki.php.net/rfc/release_cycle_update

> Currently beta is called a feature freeze but effectively it isn't. The main issue with that is that the end of alpha just means that all RFC's targeting that version must have voting finished but the implementation can be done during beta. This is however a major inconsistency because RFC implementations are often those that can have a major impact on API and ABI stability so it seems illogical to allow that but don't allow minor improvements that do not require RFC.

I think the general expectation with the current process is that an
RFC implementation would be merged reasonably shortly after feature
freeze. Extending this to the entire beta period may be risky,
especially if we're also shortening the RC period. With an
implementation merged last-minute, this gives us 2 months to iron out
any issues. With multiple RFCs merged last-minute things could become
quite overwhelming.

I also think library maintainers might want more than 2 months time to
make and test their changes, especially when it comes to BC
incompatible changes.

I'm not sure how this can be addressed. We should at least encourage
changes to be merged early in the beta cycle.

Ilija

Jakub Zelenka

2 years ago

Hi,

On Fri, Nov 10, 2023 at 5:56 PM Ilija Tovilo <tovilo.ilija@gmail.com> wrote:

> Hi Jakub
>
> Thank you for the proposal.
>
> On Fri, Nov 10, 2023 at 5:52 PM Jakub Zelenka <bukka@php.net> wrote:
> > https://wiki.php.net/rfc/release_cycle_update
>
> > Currently beta is called a feature freeze but effectively it isn't. The
> main issue with that is that the end of alpha just means that all RFC's
> targeting that version must have voting finished but the implementation can
> be done during beta. This is however a major inconsistency because RFC
> implementations are often those that can have a major impact on API and ABI
> stability so it seems illogical to allow that but don't allow minor
> improvements that do not require RFC.
>
> I think the general expectation with the current process is that an
> RFC implementation would be merged reasonably shortly after feature
> freeze. Extending this to the entire beta period may be risky,
> especially if we're also shortening the RC period. With an
> implementation merged last-minute, this gives us 2 months to iron out
> any issues. With multiple RFCs merged last-minute things could become
> quite overwhelming.
>
>

I think there should be a clear cut when the RFC can be implemented and
there should be probably still time to apply ABI breaking changes after
that time. So we could potentially decrease the time for the RFC
implementation needs to be merged. Maybe something like this:

- 2 alphas - think 2 are enough as each RM can try one release.
- 4 betas and require that all RFC has to be merged before beta3 is
released. It means we would have 2 extra betas to iron out all RFC issues
and still be able to introduce ABI breaks
- 4 RC - real feature freeze without any ABI or API breaks

What do you think?

Cheers

Jakub

Tim Düsterhus

2 years ago

Hi

On 11/10/23 21:22, Jakub Zelenka wrote:

> - 2 alphas - think 2 are enough as each RM can try one release.
> - 4 betas and require that all RFC has to be merged before beta3 is
> released. It means we would have 2 extra betas to iron out all RFC issues
> and still be able to introduce ABI breaks

Should this read: "before beta 3 is tagged"? An RFC could be merged
after the tag and before the release, and then there would only one
remaining Beta for it.

> - 4 RC - real feature freeze without any ABI or API breaks

Best regards
Tim Düsterhus

Derick Rethans

2 years ago

On 10 November 2023 20:22:27 GMT, Jakub Zelenka <bukka@php.net> wrote:

>Hi,
>
>On Fri, Nov 10, 2023 at 5:56 PM Ilija Tovilo <tovilo.ilija@gmail.com> wrote:
>
>I think there should be a clear cut when the RFC can be implemented and
>there should be probably still time to apply ABI breaking changes after
>that time. So we could potentially decrease the time for the RFC
>implementation needs to be merged. Maybe something like this:
>
>- 2 alphas - think 2 are enough as each RM can try one release.
>- 4 betas and require that all RFC has to be merged before beta3 is
>released. It means we would have 2 extra betas to iron out all RFC issues
>and still be able to introduce ABI breaks
>- 4 RC - real feature freeze without any ABI or API breaks
>
>What do you think?

I think that makes sense.

cheers
Derick

Rowan Collins

2 years ago

On 10 November 2023 16:51:57 GMT, Jakub Zelenka <bukka@php.net> wrote:

>Hello,
>
>I would like to propose a new process RFC for updates to PHP release cycle:
>
>https://wiki.php.net/rfc/release_cycle_update

Hi,

I started writing a suggestion that you add details to your RFC of what text we would remove or change in the existing policy if approved - what you've presented so far is like a good commit message, but we probably want a diff to go with it.

However, looking at the existing "policy", most of the things you want to change aren't actually in it - it doesn't even contain the word "beta". It also has parts that are obviously outdated ("Features can use branch(es) if necessary" - because the project was using SVN, where branches are costly to maintain), parts in the future tense, and even open questions (about who can vote for RMs).

So maybe what's really needed is to draft a new copy of the policy document, updating or removing those parts that are no longer relevant, and adding a timeline for the pre-release phases?

Or possibly there's a different document I should be looking at, and the RFC could contain proposed edits to that?

Regards,

--
Rowan Tommins
[IMSoP]

youkidearitai

2 years ago

2023年11月11日(土) 8:27 Rowan Tommins <rowan.collins@gmail.com>:

>
> On 10 November 2023 16:51:57 GMT, Jakub Zelenka <bukka@php.net> wrote:
> >Hello,
> >
> >I would like to propose a new process RFC for updates to PHP release cycle:
> >
> >https://wiki.php.net/rfc/release_cycle_update
>
> Hi,
>
> I started writing a suggestion that you add details to your RFC of what text we would remove or change in the existing policy if approved - what you've presented so far is like a good commit message, but we probably want a diff to go with it.
>
> However, looking at the existing "policy", most of the things you want to change aren't actually in it - it doesn't even contain the word "beta". It also has parts that are obviously outdated ("Features can use branch(es) if necessary" - because the project was using SVN, where branches are costly to maintain), parts in the future tense, and even open questions (about who can vote for RMs).
>
> So maybe what's really needed is to draft a new copy of the policy document, updating or removing those parts that are no longer relevant, and adding a timeline for the pre-release phases?
>
> Or possibly there's a different document I should be looking at, and the RFC could contain proposed edits to that?
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Hi, Internals

From mbstring point of view, PHP 8.0 is last version of not affected
"Major overhaul of mbstring".

For example, PHP 8.0's mb_detect_encoding not affected to below.
- https://github.com/php/php-src/issues/10192
- https://github.com/php/php-src/issues/7871

If PHP 8.0's EOL is one more year, There is a one-year grace period
for upgrades.

Regards
Yuya

--
---------------------------
Yuya Hamada (tekimen)
- https://tekitoh-memdhoi.info
- https://github.com/youkidearitai
-----------------------------

Derick Rethans

2 years ago

On 10 November 2023 23:27:35 GMT, Rowan Tommins <rowan.collins@gmail.com> wrote:

>On 10 November 2023 16:51:57 GMT, Jakub Zelenka <bukka@php.net> wrote:
>>Hello,
>>
>>I would like to propose a new process RFC for updates to PHP release cycle:
>>
>>https://wiki.php.net/rfc/release_cycle_update
>
>Hi,
>
>I started writing a suggestion that you add details to your RFC of what text we would remove or change in the existing policy if approved - what you've presented so far is like a good commit message, but we probably want a diff to go with it.
>
>However, looking at the existing "policy", most of the things you want to change aren't actually in it - it doesn't even contain the word "beta". It also has parts that are obviously outdated ("Features can use branch(es) if necessary" - because the project was using SVN, where branches are costly to maintain), parts in the future tense, and even open questions (about who can vote for RMs).
>
>So maybe what's really needed is to draft a new copy of the policy document, updating or removing those parts that are no longer relevant, and adding a timeline for the pre-release phases?
>
>Or possibly there's a different document I should be looking at, and the RFC could contain proposed edits to that?
>
>Regards,
>

I already have been collecting most of the policy things together in one document:

https://docs.google.com/document/d/1Wc84ZxHHamvWsZl-U2kFOrbJDEXyXFv1laePN4ijJGQ/edit?usp=drivesdk

For the same reasons really. The info was spread out a lot.

cheers
Derick

Remi Collet

2 years ago

Le 10/11/2023 à 17:51, Jakub Zelenka a écrit :

> Hello,
>
> I would like to propose a new process RFC for updates to PHP release cycle:
>
> https://wiki.php.net/rfc/release_cycle_update

> Extending security support by one year

+1

> Allowing recent regression fixes during security support

As regression are often discovered quickly, 12 months is perhaps too
much. BTW, such fix will need RM approval, so

+1

> Disallowing new features completely in RC and bug fixing release

+1

With RM exception

> Allow feature that do not require RFC in beta

+1

With RM approval

> Reduce number of RC to 4

Yes pre-release cycle is long
But RC time is used by other project for test/fix
especially for pecl extension to fix compatibility

IMHO 4 months seems fine for minor version (e.g. 8.4)
but not enough for major version (e.g. 9.0)

> The changes will apply immediately on the all currently supported

branches from PHP-8.1.

> It means that PHP-8.0 would get an extra year of security fixes if

that proposal is accepted.

Hmm... this sentence is ambiguous  ;)
Should be 8.1 for both, right ?

Remi

Unnamed Person

2 years ago

On 10-11-2023 17:51, Jakub Zelenka wrote:

> Hello,
>
> I would like to propose a new process RFC for updates to PHP release cycle:
>
> https://wiki.php.net/rfc/release_cycle_update
>
> This has been discussed between release managers to make sure that all are
> happy as some of the points impact release managers (e.g. longer security
> support).
>
> I also opened a PR to my new personal repo for RFC's if anyone has got any
> suggestion for better wording or notices any typo:
>
> https://github.com/bukka/php-rfc/pull/1
>

Thank you Jakub for putting this together. A lot of this makes sense to
me, but the shortening of the feature freeze period from effectively 18
weeks (with some exceptions) to 8 weeks concerns me.

While this is not a concern for applications in a controlled
environment, this is a concern for open source projects which don't have
control over the environment the software is being run on and therefore
generally "have to be" (try to be) deprecation-free "early", especially
packages which are used in the CI/QA chain of open source applications
(think: Composer, PHPUnit, Mockery, Pest etc) and frameworks which are
widely extended, where the extensions can't really verify their own
readiness until the framework is deprecation-free (think: WordPress and
its plugin system).

Taking that into account, I would like suggest the following:
* Yes, 4 RCs, but instead of 2 weeks between each, have 3 weeks between
each. That way the RC period remains the same, allowing the open source
world to get ready in time, while still lessening the workload.
* Regarding moving the feature freeze to the first RC: I can see the
benefits of small features still being allowed in, but deprecations
going in late is a different matter. While PHP 8.3 was "light" in
regards to the impact of deprecations, PHP 8.1 and 8.2 were a whole
different kettle of fish. With that in mind, I'd like to suggest
deprecations/removals to only be allowed in up to beta 1, with new RFC
features and other small changes being allowed in until RC1.

I hope you'll consider these suggestions.

Smile,
Juliette

Derick Rethans

2 years ago

Hi!

On Fri, 10 Nov 2023, Jakub Zelenka wrote:

> I would like to propose a new process RFC for updates to PHP release
> cycle:
>
> https://wiki.php.net/rfc/release_cycle_update

I have just published version 0.2 of this proposal — I am taken this
over from Jakub by agreement.

I've slightly reordered it, addressed some comments from this thread,
and added one new item: aligning the end of releases until Dec 31st,
20xx.

Now that we have policy documents, my next step is to prepare PRs to
https://github.com/php/policies/blob/main/feature-proposals.rst for each
item, after a more general reset of the document to reflect current
practises.

The RFC is at https://wiki.php.net/rfc/release_cycle_update

cheers,
Derick

Daniil Gentili

2 years ago

>> I would like to propose a new process RFC for updates to PHP release
>> cycle:
>>
>> https://wiki.php.net/rfc/release_cycle_update

I would also like to propose an addition, allowing patch releases to be made outside of the normal release schedule if a major core feature is broken by a fix in the previous patch release.

These out-of-schedule releases should only contain a clean revert of the fix that broke the major core feature.

I believe the "major core feature" set should include at least the garbage collector and string functions, it may be extended if needed.

I'm advocating for this change due to the fact that critical garbage collector bugs were introduced and released at least twice in the last year:

- First with a GC patch that completely broke garbage collection causing segfaults if fibers are used (https://github.com/php/php-src/pull/9810)
- And then with a GC patch that broke garbage collection causing segfaults when using weakmaps (https://github.com/php/php-src/pull/10932)

Specifically regarding the first bug, the fix for it was actually delayed by 30 days, instead of 15 (the time left until the next release, when the fix PR was merged), as a security release was made the day after the fix was merged, delaying the entire release cycle by 30 days.

I believe that bugs in major core features, introduced by fix PRs should be reverted ASAP, especially if they aren't noticed until a release, instead of breaking a core feature of the language for one month (or more if a security release delays the normal release cycle).

Also in general, I find it wrong that security releases should delay the normal cycle.

Regards,
Daniil Gentili.

Derick Rethans

2 years ago

On Thu, 21 Mar 2024, Daniil Gentili wrote:

> >> I would like to propose a new process RFC for updates to PHP release
> >> cycle:
> >>
> >> https://wiki.php.net/rfc/release_cycle_update
>
> I would also like to propose an addition, allowing patch releases to
> be made outside of the normal release schedule if a major core feature
> is broken by a fix in the previous patch release.
>
> These out-of-schedule releases should only contain a clean revert of
> the fix that broke the major core feature.
>
> I believe the "major core feature" set should include at least the
> garbage collector and string functions, it may be extended if needed.
>
> I'm advocating for this change due to the fact that critical garbage
> collector bugs were introduced and released at least twice in the last
> year:
>
> - First with a GC patch that completely broke garbage collection
>   causing segfaults if fibers are used
>   (https://github.com/php/php-src/pull/9810)
> - And then with a GC patch
>   that broke garbage collection causing segfaults when using weakmaps
>   (https://github.com/php/php-src/pull/10932)
>
> Specifically regarding the first bug, the fix for it was actually
> delayed by 30 days, instead of 15 (the time left until the next
> release, when the fix PR was merged), as a security release was made
> the day after the fix was merged, delaying the entire release cycle by
> 30 days.

Security releases have no impact on this.

> I believe that bugs in major core features, introduced by fix PRs
> should be reverted ASAP, especially if they aren't noticed until a
> release, instead of breaking a core feature of the language for one
> month (or more if a security release delays the normal release cycle).

I find this out of the scope of this RFC. I also believe that this is
not a common occurence.

> Also in general, I find it wrong that security releases should delay
> the normal cycle.

They don't? A security release is just a label in addition to a "normal"
release, in case there are bug fixes that warrant us calling them
security issues.

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

Jim Winstead

2 years ago

On Thu, Mar 21, 2024, at 10:54 AM, Derick Rethans wrote:

> Hi!
>
> On Fri, 10 Nov 2023, Jakub Zelenka wrote:
>
>> I would like to propose a new process RFC for updates to PHP release
>> cycle:
>>
>> https://wiki.php.net/rfc/release_cycle_update
>
> I have just published version 0.2 of this proposal — I am taken this
> over from Jakub by agreement.
>
> I've slightly reordered it, addressed some comments from this thread,
> and added one new item: aligning the end of releases until Dec 31st,
> 20xx.
>
> Now that we have policy documents, my next step is to prepare PRs to
> https://github.com/php/policies/blob/main/feature-proposals.rst for each
> item, after a more general reset of the document to reflect current
> practises.
>
> 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.)

Jim

Weedpacket

2 years ago

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.

Derick Rethans

2 years ago

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

Derick Rethans

2 years ago

On Thu, 21 Mar 2024, Jim Winstead wrote:

> On Thu, Mar 21, 2024, at 10:54 AM, Derick Rethans wrote:
> > Hi!
> >
> > On Fri, 10 Nov 2023, Jakub Zelenka wrote:
> >
> >> I would like to propose a new process RFC for updates to PHP release
> >> cycle:
> >>
> >> https://wiki.php.net/rfc/release_cycle_update
> >
> > I have just published version 0.2 of this proposal — I am taken this
> > over from Jakub by agreement.
> >
> > I've slightly reordered it, addressed some comments from this thread,
> > and added one new item: aligning the end of releases until Dec 31st,
> > 20xx.
> >
> > Now that we have policy documents, my next step is to prepare PRs to
> > https://github.com/php/policies/blob/main/feature-proposals.rst for each
> > item, after a more general reset of the document to reflect current
> > practises.
> >
> > 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.)

I'm planning in doing a rewrite of the whole policy document on releases
(https://github.com/php/policies/blob/main/release-process.rst) and then
RFCing the changes. That document also contains as to what a bug fix is.

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