Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97078
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
References: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
 <94840a5a-39e2-5255-e9c5-c011f00d392b@gmail.com>
 <7604bd74-bfd7-fe3b-a9b2-4717187b6c52@gmx.de>
 <CAJW__o1_95DOM1HzrSXT3Kkra6Oi0dLtP9nX=YCvwPbLvTXepw@mail.gmail.com>
To: Internals <internals@lists.php.net>
Message-ID: <3dc880ba-3a40-1927-62f6-32a2e2b2143f@gmail.com>
Date: Sat, 19 Nov 2016 21:56:24 +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: <CAJW__o1_95DOM1HzrSXT3Kkra6Oi0dLtP9nX=YCvwPbLvTXepw@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 18:35, Kalle Sommer Nielsen wrote:
> Having a fixed, forced major version does not sound that great if we 
> do not have something awesome that could only ever exist in a new 
> major version 

Again, you're looking at version numbers as primarily a branding thing 
("something awesome") rather than a technical thing ("something that 
breaks compatibility").

I think this is the biggest thing that the formal SemVer standard forces 
a developer to accept: you don't get to choose when something "deserves" 
a major version number, you MUST increment it when you break 
compatibility. As the FAQ on semver.org says, if you reach 42.0.0 very 
rapidly under SemVer, that's because your API isn't stable; pretending 
some of those versions are minor releases is just masking the problem.

If we adopted SemVer (which I'm not particularly proposing, just 
offering as comparison) there is absolutely zero chance that 4 years 
would pass without us having a single change which warranted a major 
version bump. As soon as you have one feature marked deprecated, then 
the release where that is removed is a major release, regardless of what 
else it has.

That's why I mentioned divorcing the Engine and Language versions: if we 
don't want to brand something as "PHP 8" unless it's got shinies, then 
you could brand it as "PHP 7.3 powered by Zend Engine 4.0" instead. I'm 
not sure that split does quite work, but it would at least make explicit 
the difference between brand version and compatibility version.

Regards,

-- 
Rowan Collins
[IMSoP]