Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127329
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 09 May 2025 13:09:41 +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: <CAEKnhAEchz+Uovurn9yP7Dfu1p5yK2mihJSQLJLkmX721Z152A@mail.gmail.com>
References: <CAEKnhAEchz+Uovurn9yP7Dfu1p5yK2mihJSQLJLkmX721Z152A@mail.gmail.com>
Message-ID: <c35111e43fed56ab8e77c5f4fc767f7e@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-09 12:47, schrieb Jakub Zelenka:
> I'd like to start discussion for some release process updates defined 
> in
> the following RFC / linked PR:
> 
> RFC: https://wiki.php.net/rfc/policy-release-process-update
> Policy PR: https://github.com/php/policies/pull/19

Thank you. The changes seem to accurately reflect the current practice 
and make sense to me. I however noticed that “Major” and “Minor” 
versions both effectively have the same allowances. Perhaps we could add 
some additional nuance as to what breaking changes are allowed to be 
approved by an RFC in a minor version, since breaking changes in majors 
should also require an RFC. Some thoughts:

- A minor version MUST NOT break syntax compatibility (i.e. every PHP 
program that compiles must continue to compile).
- Breaking changes in minor versions SHOULD be limited to extensions / 
the API of functions within an extension.
- The addition of deprecations themselves is not considered a breaking 
change (to resolve the discussion that comes up for each and every 
bulk-deprecation RFC, when you convert Deprecations into Exceptions 
that's on you).
- The addition of new symbols (e.g. functions or classes) might conflict 
with user-defined classes, but this is not considered a breaking change. 
An RFC should make a best effort to minimize the impact of a new 
function name by choosing among equally good names (but not 
unnecessarily choose a worse name, just because it is less likely to 
break). This is already implied by it being legal to add features 
without an RFC, but would be good to spell out explicitly.

Best regards
Tim Düsterhus