Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122806
Date: Fri, 29 Mar 2024 16:29:11 +0000 (GMT)
To: Daniil Gentili <daniil.gentili@gmail.com>
cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Release cycle update, take #2
In-Reply-To: <c69d8c30-cb12-4a62-8783-4d0cdae1120d@gmail.com>
Message-ID: <9a2e8fe0-7a3b-ff91-2abc-e7732358f1ef@php.net>
References: <CAEKnhAHs-8aQwy89=xwgiLZzn=d8DKid9-S4m95jkNzxO0hARQ@mail.gmail.com> <04736cc6-0372-8228-7d2a-7e12453a8f0c@php.net> <c69d8c30-cb12-4a62-8783-4d0cdae1120d@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
From: derick@php.net (Derick Rethans)

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