[PHP-DEV] [RFC] Release cycle update, take #2

Mailing Lists php.internals
1

Hi!

On Fri, 10 Nov 2023, Jakub Zelenka wrote:

I would like to propose a new process RFC for updates to PHP release
cycle:

PHP: 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
policies/feature-proposals.rst at main · php/policies · GitHub for each
item, after a more general reset of the document to reflect current
practises.

The RFC is at PHP: rfc:release_cycle_update

cheers,
Derick

2

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:

PHP: 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
policies/feature-proposals.rst at main · php/policies · GitHub for each
item, after a more general reset of the document to reflect current
practises.

The RFC is at PHP: 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

3

I would like to propose a new process RFC for updates to PHP release
cycle:

PHP: 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:

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.

4

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 PHP: 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.

5

On Thu, 21 Mar 2024, Daniil Gentili wrote:

>> I would like to propose a new process RFC for updates to PHP release
>> cycle:
>>
>> PHP: 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
  (GC fiber unfinished executions by arnaud-lb · Pull Request #9810 · php/php-src · GitHub)
- And then with a GC patch
  that broke garbage collection causing segfaults when using weakmaps
  (Remove WeakMap entries whose key is only reachable through the entry value by arnaud-lb · Pull Request #10932 · php/php-src · GitHub)

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: Xdebug: Support

mastodon: @derickr@phpc.social @xdebug@phpc.social

6

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:
>>
>> PHP: 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
> policies/feature-proposals.rst at main · php/policies · GitHub for each
> item, after a more general reset of the document to reflect current
> practises.
>
> The RFC is at PHP: 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
(policies/release-process.rst at main · php/policies · GitHub) 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: Xdebug: Support

mastodon: @derickr@phpc.social @xdebug@phpc.social

7

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 PHP: 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
(policies/release-process.rst at main · php/policies · GitHub).

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: Xdebug: Support

mastodon: @derickr@phpc.social @xdebug@phpc.social