Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127335
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 11 May 2025 22:14:11 +0200
To: Jakub Zelenka <bukka@php.net>
Cc: PHP internals list <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC][Discussion] Policy release process update
In-Reply-To: <CAEKnhAHuKV8gJZA_2B-XoZ+UT6u0vPAk1Zc+Q6tTGWCnk_YfxQ@mail.gmail.com>
References: <CAEKnhAEchz+Uovurn9yP7Dfu1p5yK2mihJSQLJLkmX721Z152A@mail.gmail.com>
 <c35111e43fed56ab8e77c5f4fc767f7e@bastelstu.be>
 <CAEKnhAHuKV8gJZA_2B-XoZ+UT6u0vPAk1Zc+Q6tTGWCnk_YfxQ@mail.gmail.com>
Message-ID: <08df054856f9076039b5835c0625ee6f@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

I gave this some additional thoughts.

Am 2025-05-09 13:36, schrieb Jakub Zelenka:
>> - A minor version MUST NOT break syntax compatibility (i.e. every PHP
>> program that compiles must continue to compile).
>> 
> 
> Added this one

Thinking about this more, I am not sure if having this as a MUST rule 
matches what we did in the past and I'm also not sure if it is useful to 
have. This rule prevents the addition of new keywords, since they might 
conflict with function names. Adding new symbols and adding a new 
keyword is functionally equivalent, both changes would result in a 
compile time error. Singling out the syntax change does not appear to be 
a useful distinction.

--------------------------

 From my experience in maintaining an old PHP application and upgrading 
it to support the latest and greatest PHP every year, I think the 
following points would be a good starting point to discuss:

- For backwards compatibility breaks introduced in minor versions there 
MUST be a simple (for some appropriate definition of simple) way to 
adjust the code to be compatible with both the current PHP version and 
the upcoming version. Ideally the change would be compatible with a 
wider range of past PHP versions (past 3 or so?). It must be a change 
that is simple to perform even with basic tooling (i.e. not requiring an 
IDE or static analyzers).
- Backwards compatibility breaks in minor versions MUST NOT result in 
silent behavioral differences. Instead any breaking change must be 
"obvious" when executing the program, even when having a 
less-than-stellar test suite.

Adding new symbols results in a compile time error (immediately obvious) 
and is simple to fix (rename or remove your own implementation). 
Similarly throwing a ValueError for invalid inputs is reasonably easy to 
detect by executing the affected code path (you can't miss an Exception) 
and also simple to fix (don't do that). Changing operator precedence is 
not easy to detect, thus it is unacceptable. Throwing an error when 
single-letter variables (e.g. $i) would be easy to detect, but break 
almost every program, thus would be unacceptable.

Best regards
Tim Düsterhus