Re: [PHP-DEV] [RFC] Release cycle update, take #2
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
Re: [PHP-DEV] [RFC] Release cycle update, take #2
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
Re: [PHP-DEV] [RFC] Release cycle update, take #2
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
Re: [PHP-DEV] [RFC] Release cycle update, take #2
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.
Re: [PHP-DEV] [RFC] Release cycle update, take #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: >> >> 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
Re: [PHP-DEV] [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.
[PHP-DEV] [RFC] Release cycle update, take #2
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
