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

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