Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120313
MIME-Version: 1.0
References: <CA+kxMuSUw0FJyu2+=cBgBdsE92ggoHgezeHRV6abKs=hS4bO7w@mail.gmail.com>
In-Reply-To: <CA+kxMuSUw0FJyu2+=cBgBdsE92ggoHgezeHRV6abKs=hS4bO7w@mail.gmail.com>
Date: Tue, 16 May 2023 14:46:02 +0100
Message-ID: <CALKiJKo2q0-uELWwFptCX2LAYo8m47p_aWt4kkzKyUA8WaXPWA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000077eeb105fbcfcbc3"
Subject: Re: [PHP-DEV] Planning ahead, will 8.5 exist and major version
 decisions (was: Deprecate functions with overloaded signatures)
From: rowan.collins@gmail.com (Rowan Tommins)

--00000000000077eeb105fbcfcbc3
Content-Type: text/plain; charset="UTF-8"

On Tue, 16 May 2023 at 13:39, Dan Ackroyd <Danack@basereality.com> wrote:

>
> * Are there any things being worked on that would deserve or require a
> major version bump in PHP?
>


I think there are two conflicting ideas of what a major version should be:

a) A major version is an ad hoc event that happens when something
"significant" is being changed. Any other breaking changes can piggy-back
on that major change.
b) A major version is part of the general life cycle of the project. It is
a periodic chance to make breaking changes that were held back from annual
releases.

Under (a) deprecations have no predictable duration; they will become
breaking changes whenever the opportunity arises because of a completely
disconnected decision. On the other hand, a major change can be started at
any time, with the release timeline adjusted to fit its progress.

In (b) there is a fairly clear expectation of how far away a breaking
change is once a deprecation is agreed; contributors can use this to decide
if that timescale is adequate, and users can use it to plan how to handle
the change. On the other hand, a major change faces an increased risk of
missing the major release window, and either being rushed or being held
back for several years.

I'm not convinced major changes that would run into problems with (b) are
all that common; many major features are delivered within the annual
release cycle, and many breaking changes in x.0 versions don't require a
long lead time.

A compromise might be to have a planned cycle, but with some leeway for
major projects, e.g. "a major release will happen no more often than every
4 years, and no less often than every 6"; or, to put it a different way,
"there will always be an x.3 release, and never an x.6".

Regards,
-- 
Rowan Tommins
[IMSoP]

--00000000000077eeb105fbcfcbc3--