# [RFC] Release Manager Selection - Thread: https://externals.io/message/130470 - Original archive: https://news-web.php.net/php.internals/130470 - Started by tim@bastelstu.be on 2026-03-27T18:15:56+00:00 - Messages: 13 - RFC: Release Manager Selection (Accepted) — https://externals.io/rfc/release_manager_selection_policy.md - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #130470 — tim@bastelstu.be — 2026-03-27T18:15:56+00:00 URL: https://externals.io/message/130470#130470 Hi please find the following RFC that is intended to clarify the “Release Manager Selection” policy for future PHP versions: https://wiki.php.net/rfc/release_manager_selection_policy It is written in response to this email in the PHP 8.6 RM selection thread that pointed out possible ambiguity with regard to who is allowed to apply as a RM and as to how to interpret the results of the vote: https://news-web.php.net/php.internals/130402 Best regards Tim Düsterhus --- ## #130472 — Ben Ramsey — 2026-03-28T06:35:15+00:00 URL: https://externals.io/message/130470#130472 · In reply to: #130470 > Hi > > please find the following RFC that is intended to clarify the “Release > Manager Selection” policy for future PHP versions: > > https://wiki.php.net/rfc/release_manager_selection_policy > > It is written in response to this email in the PHP 8.6 RM selection > thread that pointed out possible ambiguity with regard to who is allowed > to apply as a RM and as to how to interpret the results of the vote: > https://news-web.php.net/php.internals/130402 > > Best regards > Tim Düsterhus I'm not sure I like the notion or language of "hands-off" vs. "hands-on" release managers. What we've effectively practiced since at least PHP 8.1 is this: 1. At least 3 RMs per release 2. At least 1 of the RMs MUST be a veteran to advise the others 3. At least 2 of the RMs MUST be active during their tenure The RMs themselves decide how they want to organize their schedules. I don't think the policy needs to be much more rigid than this. It's okay for more than 1 RM to be a veteran, provided at least one of the 3 RMs is a veteran. I think it's okay for someone to be an RM on up to 2 actively supported versions of PHP at the same time. They'll need to work together with their fellow RMs to ensure their duties are adequately covered, but I disagree with designating whether anyone is "hands-on" or "hands-off." Cheers, Ben --- ## #130473 — Jordi Kroon — 2026-03-28T10:56:22+00:00 URL: https://externals.io/message/130470#130473 · In reply to: #130470 Hi Tim, Thank you for this RFC. Though I do have some concerns towards the new direction. What was the initial idea to split between rookies and veterans? As a candidate for 8.6 it feels as a chance/opportunity  to get more involved, and to build up experience as a RM (and more) as opposed to a veteran who already had the opportunity to do so. With the new policy it would essentially allow only veterans to be RM with 2 hands-on and 1 hands-off and perhaps include more favoritism to a more experienced RM rather than someone with a clean record. The terminology of rookie lowers the bar a little to allow this in my opinion. The veteran is there to advise the others. I don’t see why this needs to be hands-off. As long as there are always 2 hands-on available. So to that I am in favour of Ben’s wording. — Regards, Jordi > Hi > > please find the following RFC that is intended to clarify the “Release > Manager Selection” policy for future PHP versions: > > https://wiki.php.net/rfc/release_manager_selection_policy > > It is written in response to this email in the PHP 8.6 RM selection > thread that pointed out possible ambiguity with regard to who is allowed > to apply as a RM and as to how to interpret the results of the vote: > https://news-web.php.net/php.internals/130402 > > Best regards > Tim Düsterhus --- ## #130474 — tim@bastelstu.be — 2026-03-28T16:36:48+00:00 URL: https://externals.io/message/130470#130474 · In reply to: #130472 Hi Am 2026-03-28 07:35, schrieb Ben Ramsey: > I think it's okay for someone to be an RM on up to 2 actively supported > versions of PHP at the same time. I disagree and believe the limit for consecutive terms is very useful for the health of the project for several reasons: 1. It limits the the blast radius in case of a compromised release manager. This includes both “compromised computer” and “stolen PGP key”, but of course also soft factors like “suitcase full of nice things”. When a release manager is guaranteed to be responsible for only a single release at a time, there is a much greater chance for the release manager of the other actively supported PHP version to notice “odd things” on release day, because they'll also be actively working on a release and thus touching the same repositories. 2. It makes it more likely to have a steady supply of new “rookies” from the community. Without a limit on consecutive terms a veteran release manager could “step up” every year and if they were doing their job well, it would not be unlikely for them to be voted in every year. This would make it less likely for “rookies” to come in, who are more likely to question and as a result improve existing workflows - and also leave a hole when the veteran in question steps down for whatever reason. 3. RMs have the ultimate responsibility for a given release. As an example, with the recent policy changes around the release process (https://wiki.php.net/rfc/release_cycle_update), any change after the soft-freeze needs to be approved by RMs. But even outside this explicit approval mechanism, RMs are responsible for the stability of the release. If any given feature cannot be sufficiently stabilized in time for the gold release, it might also be necessary for it to be reverted. These decisions are necessarily happening outside of the regular RFC and voting process and thus give the individuals who happen to be RM a greater control over the project than any other individual (core developer). While I'm positive that RMs will only act in the best interest of the PHP project - and so far have no evidence of the contrary -, there could be an incentive for an RM who performs their duty on company time to bend the rules in the interest of their employer. This also ties into (1) and (2). For the above reasons, I think it is also useful for “separation of powers” if an active core developer is not also an active release manager (and of course also because the time of someone who can work on php-src is more usefully invested in doing the actual development). That's why I'm personally not applying to be RM. Best regards Tim Düsterhus --- ## #130475 — tim@bastelstu.be — 2026-03-28T18:17:37+00:00 URL: https://externals.io/message/130470#130475 · In reply to: #130473 Hi Am 2026-03-28 11:56, schrieb Jordi Kroon: > What was the initial idea to split between rookies and veterans? > > As a candidate for 8.6 it feels as a chance/opportunity  to get more > involved, and to build up experience as a RM (and more) as opposed to a > veteran who already had the opportunity to do so. > > With the new policy it would essentially allow only veterans to be RM > with 2 hands-on and 1 hands-off and perhaps include more favoritism to > a more experienced RM rather than someone with a clean record. The > terminology of rookie lowers the bar a little to allow this in my > opinion. It is certainly not my intention to exclude “rookies” from the RM role. As I mentioned in my reply to Ben, the “term limit” in the policy explicitly exists to ensure that there won't be the same few folks every year. The policy just specifies a requirement of a veteran for the “off-hands” release manager, because they are only there for advice and backup purposes, which is a role that benefits from the veteran knowledge. Given that this time we have two applications that would qualify as a veteran RM, I feel there is some ambiguity with setting up the vote that would not exist if folks would apply specifically for either “hands-on”, “hands-off” or “both”. As an example, did the veteran RMs only apply with the expectation that they would not be involved in the daily business (as was the case in the past few releases)? If more than one veteran would be voted in, would anyone of them want retract their application to “leave room” for a rookie? What if none of the veterans are amongst the first 3? With explicit “hands-on” and “hands-off” applications the “time investment” expectations are clear and it's also clear that it would be two separate votes, one selecting two “hands-on” release managers, one selecting a “hands-off” release manager (where only veterans may apply). > The veteran is there to advise the others. I don’t see why this needs > to be hands-off. As long as there are always 2 hands-on available. So > to that I am in favour of Ben’s wording. If all three RMs would be actively involved in the release process, I would want all three of them to be blocked from becoming RM for another release for the reasons I mentioned in my reply to Ben. My observations of the past several releases were that there already effectively was a “hands on” and “hands off” split, with the rookie RMs doing the daily business and the veteran RM not being actively involved (at least not publicly). Communication-wise as a core developer, I also feel that it was helpful to have just two direct and authoritative contacts in case of questions or when decisions need to be made where I could trust the opinion of any one of those two. If there were three active RMs, I feel like I would want a 2 of 3-person agreement, which just adds overhead to the communication. Best regards Tim Düsterhus --- ## #130514 — Derick Rethans — 2026-03-31T10:08:06+00:00 URL: https://externals.io/message/130470#130514 · In reply to: #130472 > > > […] > > I'm not sure I like the notion or language of "hands-off" vs. > "hands-on" release managers. What we've effectively practiced since at > least PHP 8.1 is this: > > 1. At least 3 RMs per release > 2. At least 1 of the RMs MUST be a veteran to advise the others > 3. At least 2 of the RMs MUST be active during their tenure > > The RMs themselves decide how they want to organize their schedules. I > don't think the policy needs to be much more rigid than this. > > It's okay for more than 1 RM to be a veteran, provided at least one of > the 3 RMs is a veteran. > > I think it's okay for someone to be an RM on up to 2 actively > supported versions of PHP at the same time. They'll need to work > together with their fellow RMs to ensure their duties are adequately > covered, but I disagree with designating whether anyone is "hands-on" > or "hands-off." I agree with all of these points. I don't think we even should say that a "veteran RM being one of the RMs of the *previous* PHP version". A previously active one should be fine too. cheers, Derick --- ## #130648 — tim@bastelstu.be — 2026-04-15T19:36:59+00:00 URL: https://externals.io/message/130470#130648 · In reply to: #130514 Hi I was waiting for the RM vote to end before replying here further to not influence the active vote. Am 2026-03-31 12:08, schrieb Derick Rethans: > I don't think we even should say that a "veteran RM being one of the > RMs > of the *previous* PHP version". A previously active one should be fine > too. My proposal specifically uses the term “customary” here: For PHP 8.2, 8.3, 8.4, and 8.6 it was a hands-on RM of the previous release who did the hands-off duty for the next release (PHP 8.5 was an exception to this pattern). I also think it makes sense for two reasons: - It ensures that the knowledge of the hands-off RM is up to date with the most recent practices and workflows. - It only extends the existing duty by one additional year, since the hands-off tasks can run alongside the hands-on tasks for most of the time. But I agree that it is not *necessary* to strictly follow this rule, anyone who already did hands-on duty is qualified for hands-off duty. Best regards Tim Düsterhus --- ## #130752 — tim@bastelstu.be — 2026-05-03T13:11:56+00:00 URL: https://externals.io/message/130470#130752 · In reply to: #130470 Hi Am 2026-03-27 19:15, schrieb Tim Düsterhus: > please find the following RFC that is intended to clarify the “Release > Manager Selection” policy for future PHP versions: > > https://wiki.php.net/rfc/release_manager_selection_policy I've made some changes to the PR to streamline the language a little more and use consistent terminology to refer to various “relative” PHP versions (e.g. “upcoming PHP version” for the PHP version that we're going to elect RMs for). Please check the commits for more details. I consider this a major change. Given how quiet this discussion was, I plan to vote on the RFC once the cooldown period expires. I'll send an official intent to vote when this date comes closer. Best regards Tim Düsterhus --- ## #130756 — Ben Ramsey — 2026-05-03T14:40:11+00:00 URL: https://externals.io/message/130470#130756 · In reply to: #130752 > Hi > > Am 2026-03-27 19:15, schrieb Tim Düsterhus: > > […] > > I've made some changes to the PR to streamline the language a little > more and use consistent terminology to refer to various “relative” PHP > versions (e.g. “upcoming PHP version” for the PHP version that we're > going to elect RMs for). > > Please check the commits for more details. > > I consider this a major change. Given how quiet this discussion was, I > plan to vote on the RFC once the cooldown period expires. I'll send an > official intent to vote when this date comes closer. > > Best regards > Tim Düsterhus I still dislike the distinction of "hands-on" and "hands-off" as descriptors for these roles and disagree with their use in defining these roles. I said as much in my earlier message, and I'll be voting "no" for the changes to the policy as it currently stands. I think I'm in agreement with the rest of the proposal. If we can come up with better terminology around the roles and make the roles less about their level of involvement, then I'll probably change my vote to a "yes." Cheers, Ben --- ## #130757 — Ben Ramsey — 2026-05-03T15:29:20+00:00 URL: https://externals.io/message/130470#130757 · In reply to: #130756 > > > […] > > > I still dislike the distinction of "hands-on" and "hands-off" as > descriptors for these roles and disagree with their use in defining > these roles. I said as much in my earlier message, and I'll be voting > "no" for the changes to the policy as it currently stands. > > I think I'm in agreement with the rest of the proposal. If we can come > up with better terminology around the roles and make the roles less > about their level of involvement, then I'll probably change my vote to a > "yes." > > Cheers, > Ben > Following up on my earlier messages, I've been thinking more about the terminology and have come up with a concrete suggestion. From my perspective, the distinction between the two roles is fundamentally about experience, not involvement. I don't want to define the roles around involvement. The policy itself already uses the word "veteran" to describe the qualification for the advisory role, so I'd suggest elevating that to the name of the role itself: "Veteran Release Manager" for the advisor with prior experience, and "Co-release Manager" for the other two. This reuses terminology already present in the policy text and defines the roles by what qualifies someone for them rather than what they're expected to do or not do. It also leaves room for the RMs themselves to organize their work as they see fit. With these changes I'd be comfortable changing my vote to "yes." Cheers, Ben --- ## #130763 — Joe Ferguson — 2026-05-04T15:22:32+00:00 URL: https://externals.io/message/130470#130763 · In reply to: #130757 I agree with Ben, I would prefer "Veteran Release Manager" / "Co-release Manager" over "hands on" / "hands off". The "hands off" sounds negative to me. > > > […] > > > Following up on my earlier messages, I've been thinking more about the > terminology and have come up with a concrete suggestion. > > From my perspective, the distinction between the two roles is > fundamentally about experience, not involvement. I don't want to define > the roles around involvement. The policy itself already uses the word > "veteran" to describe the qualification for the advisory role, so I'd > suggest elevating that to the name of the role itself: "Veteran Release > Manager" for the advisor with prior experience, and "Co-release Manager" > for the other two. This reuses terminology already present in the policy > text and defines the roles by what qualifies someone for them rather > than what they're expected to do or not do. It also leaves room for the > RMs themselves to organize their work as they see fit. > > With these changes I'd be comfortable changing my vote to "yes." > > Cheers, > Ben > -- - Joe Ferguson JoeFerguson.me --- ## #130764 — tim@bastelstu.be — 2026-05-04T15:58:07+00:00 URL: https://externals.io/message/130470#130764 · In reply to: #130757 Hi Am 2026-05-03 17:29, schrieb Ben Ramsey: > From my perspective, the distinction between the two roles is > fundamentally about experience, not involvement. I refer to my reply to Jordi, particularly the second paragraph. > I don't want to define the roles around involvement. The policy is describing the current practice in a formal way. For the past several releases only two of the three release managers have actually made releases [1]. For PHP 8.5 specifically, all the public communication and PR review during the feature freeze has been done by the two “rookies” / “hands-on” RMs Daniel and Volker. I'd argue that this hands-on and hands-off split is already something that is expected by the community. > The policy itself already uses the word "veteran" to describe the > qualification for the advisory role, so I'd suggest elevating that to > the name of the role itself: "Veteran Release Manager" for the advisor > with prior experience, and "Co-release Manager" for the other two. This > reuses terminology already present in the policy text and defines the > roles by what qualifies someone for them rather than what they're > expected to do or not do. It also leaves room for the RMs themselves to > organize their work as they see fit. I'm not seeing the term “co-release manager” in the policy. I'd also like to note how you used the word “advisor” to refer to what my proposal refers to as “hands-off”. Best regards Tim Düsterhus [1] With one exception for PHP 8.3.1 and one for PHP 8.0.30, the latter of which has been made without even being an official RM. I remember this causing some troubles for Docker, which didn't expect the “extra PGP key”. ========= 8.0 ========= php-8.0.0 Sara Golemon php-8.0.0RC2 Sara Golemon php-8.0.0RC3 Gabriel Caruso php-8.0.0RC4 Gabriel Caruso php-8.0.0RC5 Gabriel Caruso php-8.0.0alpha1 Sara Golemon php-8.0.0alpha2 Gabriel Caruso php-8.0.0alpha3 Gabriel Caruso php-8.0.0beta1 Gabriel Caruso php-8.0.0beta2 Sara Golemon php-8.0.0beta3 Gabriel Caruso php-8.0.0beta4 Sara Golemon php-8.0.0rc1 Gabriel Caruso php-8.0.1 Gabriel Caruso php-8.0.1RC1 Gabriel Caruso php-8.0.2 Gabriel Caruso php-8.0.2RC1 Gabriel Caruso php-8.0.3 Sara Golemon php-8.0.3RC1 Sara Golemon php-8.0.4RC1 Gabriel Caruso php-8.0.5 Gabriel Caruso php-8.0.5RC1 Gabriel Caruso php-8.0.6 Sara Golemon php-8.0.7 Sara Golemon php-8.0.7RC1 Sara Golemon php-8.0.8 Gabriel Caruso php-8.0.8RC1 Gabriel Caruso php-8.0.9 Gabriel Caruso php-8.0.9RC1 Sara Golemon php-8.0.10 Gabriel Caruso php-8.0.10RC1 Gabriel Caruso php-8.0.11 Sara Golemon php-8.0.11RC1 Sara Golemon php-8.0.12 Gabriel Caruso php-8.0.12RC1 Gabriel Caruso php-8.0.13 Sara Golemon php-8.0.13RC1 Sara Golemon php-8.0.14 Sara Golemon php-8.0.14RC1 Sara Golemon php-8.0.15 Gabriel Caruso php-8.0.15RC1 Gabriel Caruso php-8.0.16 Sara Golemon php-8.0.16RC1 Sara Golemon php-8.0.17 Gabriel Caruso php-8.0.17RC1 Gabriel Caruso php-8.0.18 Sara Golemon php-8.0.18RC1 Sara Golemon php-8.0.19 Gabriel Caruso php-8.0.19RC1 Gabriel Caruso php-8.0.20 Sara Golemon php-8.0.20RC1 Sara Golemon php-8.0.21 Gabriel Caruso php-8.0.21RC1 Gabriel Caruso php-8.0.22 Gabriel Caruso php-8.0.22RC1 Gabriel Caruso php-8.0.23 Sara Golemon php-8.0.23RC1 Gabriel Caruso php-8.0.24 Sara Golemon php-8.0.24RC1 Sara Golemon php-8.0.25 Gabriel Caruso php-8.0.25RC1 Gabriel Caruso php-8.0.26 Sara Golemon php-8.0.26RC1 Sara Golemon php-8.0.28 Gabriel Caruso php-8.0.29 Gabriel Caruso php-8.0.30 Ben Ramsey ========= 8.1 ========= php-8.1.0 Patrick Allaert php-8.1.0RC3 Ben Ramsey php-8.1.0RC4 Ben Ramsey php-8.1.0RC6 Ben Ramsey php-8.1.0alpha3 Ben Ramsey php-8.1.0beta1 Ben Ramsey php-8.1.0beta2 Ben Ramsey php-8.1.0beta3 Ben Ramsey php-8.1.1 Patrick Allaert php-8.1.1RC1 Patrick Allaert php-8.1.2 Ben Ramsey php-8.1.2RC1 Patrick Allaert php-8.1.3 Patrick Allaert php-8.1.3RC1 Patrick Allaert php-8.1.4 Ben Ramsey php-8.1.4RC1 Patrick Allaert php-8.1.5 Patrick Allaert php-8.1.5RC1 Patrick Allaert php-8.1.6 Ben Ramsey php-8.1.6RC1 Ben Ramsey php-8.1.7 Ben Ramsey php-8.1.7RC1 Patrick Allaert php-8.1.8 Ben Ramsey php-8.1.8RC1 Ben Ramsey php-8.1.9 Patrick Allaert php-8.1.9RC1 Patrick Allaert php-8.1.10 Ben Ramsey php-8.1.10RC1 Ben Ramsey php-8.1.11 Patrick Allaert php-8.1.11RC1 Patrick Allaert php-8.1.12 Ben Ramsey php-8.1.12RC1 Ben Ramsey php-8.1.13 Patrick Allaert php-8.1.13RC1 Patrick Allaert php-8.1.14 Ben Ramsey php-8.1.14RC1 Ben Ramsey php-8.1.15 Patrick Allaert php-8.1.15RC1 Patrick Allaert php-8.1.16 Ben Ramsey php-8.1.17 Patrick Allaert php-8.1.17RC1 Patrick Allaert php-8.1.18 Ben Ramsey php-8.1.18RC1 Ben Ramsey php-8.1.19 Patrick Allaert php-8.1.19RC1 Patrick Allaert php-8.1.20 Ben Ramsey php-8.1.20RC1 Ben Ramsey php-8.1.21 Patrick Allaert php-8.1.21RC1 Patrick Allaert php-8.1.22 Ben Ramsey php-8.1.22RC1 Ben Ramsey php-8.1.23 Patrick Allaert php-8.1.23RC1 Patrick Allaert php-8.1.24 Ben Ramsey php-8.1.24RC1 Ben Ramsey php-8.1.25 Patrick Allaert php-8.1.25RC1 Patrick Allaert php-8.1.26 Ben Ramsey php-8.1.26RC1 Ben Ramsey php-8.1.27 Patrick Allaert php-8.1.27RC1 Patrick Allaert php-8.1.28 Ben Ramsey php-8.1.29 Ben Ramsey php-8.1.30 Ben Ramsey php-8.1.31 Patrick Allaert php-8.1.32 Ben Ramsey php-8.1.33 Ben Ramsey php-8.1.34 Ben Ramsey ========= 8.2 ========= php-8.2.0 Sergey Panteleev php-8.2.0RC1 Pierrick Charron php-8.2.0RC2 Sergey Panteleev php-8.2.0RC3 Pierrick Charron php-8.2.0RC4 Sergey Panteleev php-8.2.0RC5 Pierrick Charron php-8.2.0RC6 Sergey Panteleev php-8.2.0RC7 Pierrick Charron php-8.2.0alpha1 Sergey Panteleev php-8.2.0alpha2 Pierrick Charron php-8.2.0alpha3 Sergey Panteleev php-8.2.0beta1 Pierrick Charron php-8.2.0beta2 Sergey Panteleev php-8.2.0beta3 Pierrick Charron php-8.2.1 Pierrick Charron php-8.2.1RC1 Pierrick Charron php-8.2.2 Sergey Panteleev php-8.2.2RC1 Sergey Panteleev php-8.2.3 Pierrick Charron php-8.2.4 Sergey Panteleev php-8.2.4RC1 Sergey Panteleev php-8.2.5 Pierrick Charron php-8.2.5RC1 Pierrick Charron php-8.2.6 Sergey Panteleev php-8.2.6RC1 Sergey Panteleev php-8.2.7 Pierrick Charron php-8.2.7RC1 Pierrick Charron php-8.2.8 Sergey Panteleev php-8.2.8RC1 Sergey Panteleev php-8.2.9 Sergey Panteleev php-8.2.9RC1 Sergey Panteleev php-8.2.10 Pierrick Charron php-8.2.10RC1 Pierrick Charron php-8.2.11 Sergey Panteleev php-8.2.11RC1 Sergey Panteleev php-8.2.12 Pierrick Charron php-8.2.12RC1 Pierrick Charron php-8.2.13 Sergey Panteleev php-8.2.13RC1 Sergey Panteleev php-8.2.14 Pierrick Charron php-8.2.14RC1 Pierrick Charron php-8.2.15 Sergey Panteleev php-8.2.15RC1 Sergey Panteleev php-8.2.16 Pierrick Charron php-8.2.16RC1 Pierrick Charron php-8.2.17 Sergey Panteleev php-8.2.17RC1 Sergey Panteleev php-8.2.17RC2 Sergey Panteleev php-8.2.18 Pierrick Charron php-8.2.18RC1 Pierrick Charron php-8.2.19 Sergey Panteleev php-8.2.19RC1 Sergey Panteleev php-8.2.20 Pierrick Charron php-8.2.20RC1 Pierrick Charron php-8.2.21 Sergey Panteleev php-8.2.21RC1 Sergey Panteleev php-8.2.22 Pierrick Charron php-8.2.22RC1 Pierrick Charron php-8.2.23 Sergey Panteleev php-8.2.23RC1 Sergey Panteleev php-8.2.24 Pierrick Charron php-8.2.24RC1 Pierrick Charron php-8.2.25 Sergey Panteleev php-8.2.25RC1 Sergey Panteleev php-8.2.26 Pierrick Charron php-8.2.26RC1 Pierrick Charron php-8.2.27 Sergey Panteleev php-8.2.27RC1 Sergey Panteleev php-8.2.28 Pierrick Charron php-8.2.29 Sergey Panteleev php-8.2.30 Pierrick Charron ========= 8.3 ========= php-8.3.0 Jakub Zelenka php-8.3.0RC1 Jakub Zelenka php-8.3.0RC2 Eric Mann php-8.3.0RC3 Jakub Zelenka php-8.3.0RC4 Eric Mann php-8.3.0RC5 Jakub Zelenka php-8.3.0RC6 Eric Mann php-8.3.0alpha1 Jakub Zelenka php-8.3.0alpha2 Eric Mann php-8.3.0alpha3 Jakub Zelenka php-8.3.0beta1 Eric Mann php-8.3.0beta2 Jakub Zelenka php-8.3.0beta3 Eric Mann php-8.3.1 Pierrick Charron php-8.3.1RC1 Eric Mann php-8.3.1RC1-clean Eric Mann php-8.3.1RC2 Eric Mann php-8.3.1RC3 Eric Mann php-8.3.2 Jakub Zelenka php-8.3.2RC1 Jakub Zelenka php-8.3.3 Eric Mann php-8.3.3RC1 Eric Mann php-8.3.4 Jakub Zelenka php-8.3.4RC1 Jakub Zelenka php-8.3.5 Eric Mann php-8.3.5RC1 Eric Mann php-8.3.6 Eric Mann php-8.3.7 Jakub Zelenka php-8.3.7RC1 Jakub Zelenka php-8.3.8 Eric Mann php-8.3.8RC1 Eric Mann php-8.3.9 Jakub Zelenka php-8.3.9RC1 Jakub Zelenka php-8.3.10 Eric Mann php-8.3.10RC1 Eric Mann php-8.3.11 Jakub Zelenka php-8.3.11RC1 Jakub Zelenka php-8.3.11RC2 Jakub Zelenka php-8.3.12 Eric Mann php-8.3.12RC1 Eric Mann php-8.3.13 Jakub Zelenka php-8.3.13RC1 Jakub Zelenka php-8.3.14 Eric Mann php-8.3.14RC1 Eric Mann php-8.3.15 Jakub Zelenka php-8.3.15RC1 Jakub Zelenka php-8.3.16 Eric Mann php-8.3.16RC1 Eric Mann php-8.3.17 Jakub Zelenka php-8.3.17RC1 Jakub Zelenka php-8.3.18 Eric Mann php-8.3.18RC1 Eric Mann php-8.3.19 Eric Mann php-8.3.20 Jakub Zelenka php-8.3.20RC1 Jakub Zelenka php-8.3.21 Eric Mann php-8.3.21RC1 Eric Mann php-8.3.22 Jakub Zelenka php-8.3.22RC1 Jakub Zelenka php-8.3.23 Eric Mann php-8.3.23RC1 Eric Mann php-8.3.24 Jakub Zelenka php-8.3.24RC1 Jakub Zelenka php-8.3.25 Eric Mann php-8.3.25RC1 Eric Mann php-8.3.26 Jakub Zelenka php-8.3.26RC1 Jakub Zelenka php-8.3.27 Eric Mann php-8.3.27RC1 Eric Mann php-8.3.28 Jakub Zelenka php-8.3.28RC1 Jakub Zelenka php-8.3.29 Eric Mann php-8.3.29RC1 Eric Mann php-8.3.30 Jakub Zelenka php-8.3.30RC1 Jakub Zelenka ========= 8.4 ========= php-8.4.0 Saki Takamachi php-8.4.0RC1 Saki Takamachi php-8.4.0RC2 Calvin Buckley php-8.4.0RC3 Saki Takamachi php-8.4.0RC4 Calvin Buckley php-8.4.0alpha1 Saki Takamachi php-8.4.0alpha2 Calvin Buckley php-8.4.0alpha3 Saki Takamachi php-8.4.0alpha4 Saki Takamachi php-8.4.0beta1 Calvin Buckley php-8.4.0beta2 Calvin Buckley php-8.4.0beta3 Calvin Buckley php-8.4.0beta4 Saki Takamachi php-8.4.0beta5 Calvin Buckley php-8.4.1 Saki Takamachi php-8.4.2 Calvin Buckley php-8.4.2RC1 Calvin Buckley php-8.4.3 Saki Takamachi php-8.4.3RC1 Saki Takamachi php-8.4.4 Calvin Buckley php-8.4.4RC1 Calvin Buckley php-8.4.4RC2 Calvin Buckley php-8.4.5 Saki Takamachi php-8.4.5RC1 Saki Takamachi php-8.4.6 Calvin Buckley php-8.4.6RC1 Calvin Buckley php-8.4.7 Saki Takamachi php-8.4.7RC1 Saki Takamachi php-8.4.7RC2 Saki Takamachi php-8.4.8 Calvin Buckley php-8.4.8RC1 Calvin Buckley php-8.4.9 Saki Takamachi php-8.4.9RC1 Saki Takamachi php-8.4.10 Saki Takamachi php-8.4.11 Calvin Buckley php-8.4.11RC1 Calvin Buckley php-8.4.12 Saki Takamachi php-8.4.12RC1 Saki Takamachi php-8.4.13 Calvin Buckley php-8.4.13RC1 Calvin Buckley php-8.4.14 Saki Takamachi php-8.4.14RC1 Saki Takamachi php-8.4.15 Calvin Buckley php-8.4.15RC1 Calvin Buckley php-8.4.16 Saki Takamachi php-8.4.16RC1 Saki Takamachi php-8.4.17 Calvin Buckley php-8.4.17RC1 Calvin Buckley php-8.4.18 Saki Takamachi php-8.4.18RC1 Saki Takamachi php-8.4.19 Calvin Buckley php-8.4.19RC1 Calvin Buckley php-8.4.20 Saki Takamachi php-8.4.20RC1 Saki Takamachi php-8.4.21RC1 Calvin Buckley ========= 8.5 ========= php-8.5.0 Daniel Scherzer php-8.5.0RC1 Daniel Scherzer php-8.5.0RC2 Volker Dusch php-8.5.0RC3 Daniel Scherzer php-8.5.0RC4 Volker Dusch php-8.5.0RC5 Daniel Scherzer php-8.5.0alpha1 Daniel Scherzer php-8.5.0alpha2 Volker Dusch php-8.5.0alpha3 Daniel Scherzer php-8.5.0alpha4 Daniel Scherzer php-8.5.0beta1 Volker Dusch php-8.5.0beta2 Daniel Scherzer php-8.5.0beta3 Volker Dusch php-8.5.1 Volker Dusch php-8.5.1RC1 Volker Dusch php-8.5.1RC2 Volker Dusch php-8.5.2 Daniel Scherzer php-8.5.2RC1 Daniel Scherzer php-8.5.3 Volker Dusch php-8.5.3RC1 Volker Dusch php-8.5.4 Daniel Scherzer php-8.5.4RC1 Daniel Scherzer php-8.5.5 Volker Dusch php-8.5.5RC1 Volker Dusch php-8.5.6RC1 Daniel Scherzer php-8.5.6RC2 Daniel Scherzer php-8.5.6RC3 Daniel Scherzer --- ## #130909 — tim@bastelstu.be — 2026-05-16T13:00:38+00:00 URL: https://externals.io/message/130470#130909 · In reply to: #130752 Hi Am 2026-05-03 15:11, schrieb Tim Düsterhus: > I consider this a major change. Given how quiet this discussion was, I > plan to vote on the RFC once the cooldown period expires. I'll send an > official intent to vote when this date comes closer. The cooldown will expire in roughly 24 hours. I plan to start the vote early next week. Best regards Tim Düsterhus