Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127338
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 13 May 2025 12:56:30 +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: <CAEKnhAG399ceuKtk3Hjk0qhnj8rkxsOH4t5kWrmKK7WpphJUEw@mail.gmail.com>
References: <CAEKnhAEchz+Uovurn9yP7Dfu1p5yK2mihJSQLJLkmX721Z152A@mail.gmail.com>
 <c35111e43fed56ab8e77c5f4fc767f7e@bastelstu.be>
 <CAEKnhAHuKV8gJZA_2B-XoZ+UT6u0vPAk1Zc+Q6tTGWCnk_YfxQ@mail.gmail.com>
 <08df054856f9076039b5835c0625ee6f@bastelstu.be>
 <CAEKnhAG399ceuKtk3Hjk0qhnj8rkxsOH4t5kWrmKK7WpphJUEw@mail.gmail.com>
Message-ID: <0c55c9b700ddac8810974ca62522c3fd@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

Am 2025-05-13 12:13, schrieb Jakub Zelenka:
>>  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).
>> 
> 
> If I understand it correctly, this sounds really more like completely 
> new
> rule that we don't currently have so I would rather not add it. We 
> don't
> have this relation differences between X.Y and X.(Y+2) to do some extra
> breaks so it's more for a separate RFC. I'm also not a big fan of such
> change to be honest.

We don't currently have any rules at all, except for “when the RFC 
approves the break, then it's okay”. I was trying to find some guideline 
for BC breaks that might be okay in a minor (when approved) and BC 
breaks that are never okay in a minor.

The application in question is in a very similar position that PHP 
itself is, it has a large public API that "third party" developers rely 
on and a long development history. BC breaks sometimes are not avoidable 
when you try to move forward. Basically the rule of thumb for a breaking 
change in a minor version was that "most third party add-on should be 
adaptable with minimal changes, while remaining compatible with both 
minor versions after making these minimal changes".

>> 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.
> 
> 
> This makes sense but might be a bit too specific. Did you mean to also
> include it in this policy?

That paragraph is intended as an example for my train of thought / how I 
would interpret my suggested guidelines for hypothetical breaking 
changes. Of course I do not expect anyone to propose an RFC to disallow 
single-letter variables (not even in a major).

Best regards
Tim Düsterhus