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
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/130402Best 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:
- At least 3 RMs per release
- At least 1 of the RMs MUST be a veteran to advise the others
- 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
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:
- 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.
- 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.
- 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
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/130402I'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:
- At least 3 RMs per release
- At least 1 of the RMs MUST be a veteran to advise the others
- 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
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
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/130402Best regards
Tim Düsterhus
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
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:
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
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: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
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: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üsterhusI 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
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.
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: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üsterhusI 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,
BenFollowing 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
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
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