Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97068
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
References: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
 <94840a5a-39e2-5255-e9c5-c011f00d392b@gmail.com>
 <CAJW__o2ffCSRPTZ+QojSBoL6YA0ZgP_iGtW00WHD104aCziWEg@mail.gmail.com>
 <CADyq6sLmAXsZiXoA9ewuv_LmZnQuozfDCQNwXs3G2=3Yzc5DGA@mail.gmail.com>
To: Internals <internals@lists.php.net>
Message-ID: <70039124-d8d7-e139-b0e3-6b2d2ed51aff@gmail.com>
Date: Sat, 19 Nov 2016 18:34:21 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <CADyq6sLmAXsZiXoA9ewuv_LmZnQuozfDCQNwXs3G2=3Yzc5DGA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2
From: rowan.collins@gmail.com (Rowan Collins)

On 19/11/2016 17:56, Marco Pivetta wrote:
> On Sat, Nov 19, 2016 at 6:42 PM, Kalle Sommer Nielsen <kalle@php.net 
> <mailto:kalle@php.net>> wrote:
>
>     So to answer your question in a short without much more rambling: I
>     think we should deprecate in x.z, then remove in x.z+1 depending on
>     the feature, if we say "Oh let's remove this in the next major",
>     chances are that major won't even be branches for years, and at that
>     time, it could be forgotten.
>
>
> That will end up breaking the "expected" (because it's not that way 
> anyway, but almost) SemVer approach, diminishing the trust from 
> consumers in any kind of upgrade.
> Most of the current open-source libs out there are trying to push for 
> SemVer - having PHP not following that seems like a huge mess to me.
>

I agree with this, to an extent. If we formally disavow any meaning of 
"major release" other than branding, the expectation is less of an issue 
in itself. But it's interesting that PostgreSQL is moving to a 2-part 
version numbering: instead of the annual feature releases being 9.7.0, 
9.8.0, 9.9.0 etc, they will be 10.0, 11.0, 12.0, thus eliminating debate 
about which releases should be classed as "major".


> Like you also mention, major versions are really rare and I
> think it should be kept that way, or at least until we reach a point
> where we literally cannot improve PHP7 anymore without major changes,
> such as the case for PHP 5.6 was.

What is a "major change", if you want to abandon the link to 
compatibility? Do you mean "headline-grabbing feature", i.e. versioning 
as a brand?


> With our current model, that means that when we deprecate something,
> users got a year to upgrade their code, if they are bleeding edge
> users, but most are likely not, so they have more time to upgrade the
> code

This is a recipe for massive version fragmentation. When x.3 comes out, 
some people will be stuck on x.0, some on x.1, some on x.2, etc; library 
authors won't be able to take advantage of the features introduced in 
x.3, and everyone has to remember just what's new in each release.

I actually think major releases should be *more* common, to reduce the 
temptation to "bend" the rules, and break compatibility early. The 
policy could be as simple as "every major release will have between 3 
and 5 minor releases". Then the earliest release of 8.0 would be after 
7.2 (late 2018 / early 2019), and the latest would be after 7.4 (late 
2020 / early 2021).

Having a road map in advance also means you can branch early, break 
things, and know how long you're going to have to maintain that branch for.

Regards,

-- 
Rowan Collins
[IMSoP]