[RFC] [Discussion] Release cycle update View as Markdown

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

Hi,

Hi Jakub

Thank you for the proposal.

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

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

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]

--

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

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

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.

Hi!

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