Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127205
Precedence: bulk
MIME-Version: 1.0
References: <CAPTD5yFaQL58uJ3Focij9HKT-u-70fTDdzBWsqxpAru2YRZaqQ@mail.gmail.com>
 <YAFPTpeOTAw7NcYOqaFhRhEMMZTLzLtqVbMlPKWI-P2FwlxvoOfdKBQWyxO8Y_uXA903u1fwjP7reP45oyfvbyHy_W7gnP4HIrWxXP1TE7Y=@gpb.moe>
In-Reply-To: <YAFPTpeOTAw7NcYOqaFhRhEMMZTLzLtqVbMlPKWI-P2FwlxvoOfdKBQWyxO8Y_uXA903u1fwjP7reP45oyfvbyHy_W7gnP4HIrWxXP1TE7Y=@gpb.moe>
Date: Sun, 27 Apr 2025 21:37:34 +0200
Message-ID: <CAPTD5yGCMSLtjMSi6V+1-OhMs=LN-7dVkfGsGO41bq1t1FygrA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009c2f0b0633c7b309"
From: jorg.sowa@gmail.com (Jorg Sowa)

--0000000000009c2f0b0633c7b309
Content-Type: text/plain; charset="UTF-8"

Thank you all for the feedback.

> I don't fundamentally disagree with the attempt to codify something
> here, but ultimately the PHP language does and will continue to profit
> from some flexibility in these regards.

@Bob, I agree that flexibility is desired. That's why I would like to have
rather guideline that instruction. It could be achieved with changing MUST
to SHOULD.

> This, to me, indicates a clear consensus within the core dev team that
these sorts of BC breaks are accepted and routine.

@Gina, But that's clearly against current policy which clearly states for
both minor and patch versions [1]:

> Backward compatibility must be kept
-
- Honestly everything comes from lack of clear ownership of the project.
The only thing I wanted to achieve is that my PR (8 months after creation)
and others similar that I wanted to create is merged. First through soft
consensus, and when that failed through RFC. While at the same time similar
PRs are already merged. It's a bit inconsistent right?

- Regarding to your investigation, I don't argue with it. But according to
the CURRENT policy my RFC should be rejected along with many others.
However, this concern was not raised. The next RFC [2] fixing the problem
was also based on the assumption what's the direction of project (moving
into the enums). Similar thing is about namespaces, there is no clear
policy about moving out functions from global space to namespaces. New
contributors are not aware of such tendencies, neither was I.

And I don't think that I'm suitable to proceed with the policy change as I
barely contribute to the project and don't have much experience and
knowledge about all reasons behind past decisions. And if so I'm leaving
this matter to the core developers to decide. I don't care if it's
deprecation, warning, one version prior or the same. I don't want to waste
more time on such discussion. I just want clear, consistent rules that are
respected by everyone.

- Kind regards,
- Jorg
-
[1] https://wiki.php.net/rfc/releaseprocess
[2]
https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum

--0000000000009c2f0b0633c7b309
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thank you all for the feedback.<br><br>&gt;=20
I don&#39;t fundamentally disagree with the attempt to codify something <br=
>&gt; here, but ultimately the PHP language does and will continue to profi=
t <br>&gt; from some flexibility in these regards.<br><br>@Bob, I agree tha=
t flexibility is desired. That&#39;s why I would like to have rather guidel=
ine that instruction. It could be achieved with changing MUST to SHOULD.</d=
iv><div><br>&gt; This, to me, indicates a clear consensus within the core d=
ev team that these sorts of BC breaks are accepted and routine.<br><br></di=
v>@Gina, But that&#39;s clearly against current policy which clearly states=
 for both minor and patch versions [1]:<br><br>&gt; Backward compatibility =
must be kept<li class=3D"gmail-level2">
<br></li><li class=3D"gmail-level2">Honestly everything comes from lack of =
clear ownership of the project. The only thing I wanted to achieve is that =
my PR (8 months after creation) and others similar that I wanted to create =
is merged. First through soft consensus, and when that failed through RFC. =
While at the same time similar PRs are already merged. It&#39;s a bit incon=
sistent right?<br><br></li><li class=3D"gmail-level2">Regarding to your inv=
estigation, I don&#39;t argue with it. But according to the CURRENT policy =
my RFC should be rejected along with many others. However, this concern was=
 not raised. The next RFC [2] fixing the problem was also based on the assu=
mption what&#39;s the direction of project (moving into the enums). Similar=
 thing is about namespaces, there is no clear policy about moving out funct=
ions from global space to namespaces. New contributors are not aware of suc=
h tendencies, neither was I.<br><br>And I don&#39;t think that I&#39;m suit=
able to proceed with the policy change as I barely contribute to the projec=
t and don&#39;t have much experience and knowledge about all reasons behind=
 past decisions. And if so I&#39;m leaving this matter to the core develope=
rs to decide.  I don&#39;t care if it&#39;s deprecation, warning, one versi=
on prior or the same. I don&#39;t want to waste more time on such discussio=
n. I just want clear, consistent rules that are respected by everyone.<br><=
br></li><li class=3D"gmail-level2">Kind regards,<br></li><li class=3D"gmail=
-level2">Jorg</li><li class=3D"gmail-level2"><br>[1] <a href=3D"https://wik=
i.php.net/rfc/releaseprocess">https://wiki.php.net/rfc/releaseprocess</a><b=
r>[2] <a href=3D"https://wiki.php.net/rfc/correctly_name_the_rounding_mode_=
and_make_it_an_enum">https://wiki.php.net/rfc/correctly_name_the_rounding_m=
ode_and_make_it_an_enum</a><br><br></li></div>

--0000000000009c2f0b0633c7b309--