Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97094
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.172 as permitted sender)
To: Internals <internals@lists.php.net>
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>
 <3dc880ba-3a40-1927-62f6-32a2e2b2143f@gmail.com>
 <CAJW__o2mp5uwBLbSkMg7dCOz3x5Jj7YjUCk3fD1A+RUbD6H7iA@mail.gmail.com>
Message-ID: <c9b9dadd-6ccc-e6e4-13b9-6be241134890@gmail.com>
Date: Sun, 20 Nov 2016 22:32:15 +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__o2mp5uwBLbSkMg7dCOz3x5Jj7YjUCk3fD1A+RUbD6H7iA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2
From: rowan.collins@gmail.com (Rowan Collins)

On 19/11/2016 23:05, Kalle Sommer Nielsen wrote:
> 2016-11-19 22:56 GMT+01:00 Rowan Collins <rowan.collins@gmail.com>:
>> Again, you're looking at version numbers as primarily a branding thing
>> ("something awesome") rather than a technical thing ("something that breaks
>> compatibility").
> Yes because that has been our past model for a long time. Like I
> mentioned, PHP 5.3 should probably have been a major considering the
> changes it did.

Agreed that it's the past model, and agreed that 5.3 was misnamed 
whichever way you look at it.

The fact that something used to be done a particular way doesn't mean 
that was the best way, though. It's also not what the current release 
process specifies, in my opinion.


> It wasn't until PHP 5.3 that we introduced
> E_DEPREPCATED and actively started taking out problematic features
> which in the past had caused issues with the usual group of people who
> don't care to read the manual, so we gave those features a little
> longer life span while informing the developers that we are gonna
> remove it.
>
> Basically before we started to get all political of things

I'm not sure what you mean by "political". The big challenge which comes 
up again and again, is that take up of new versions of PHP is low. You 
can blame the users for that if you like, but the reality is there's no 
point rushing your shiny feature into a release that 90% of the user 
base won't install.

Well-publicised deprecations, and a strict adherence to compatibility, 
build trust that upgrading won't be a major headache, meaning new 
features actually get to users *faster*. And to return to the topic at 
hand, knowing how long something will be deprecated before it's removed 
helps people plan ahead.


> If we were to rename past releases to a scheme by SemVer, then that
> would pretty much have been a yearly major, that is extremely poor
> versioning in my opinion when we retrain such a high backwards
> compatibility rate otherwise.

If every release contained breaking changes, then the release process 
RFC has failed. It would be extremely poor versioning not because we'd 
somehow run out of version numbers, but because it means we've made 
upgrading harder than it should be.

Let me quote that SemVer FAQ in full:

> /Q: //If even the tiniest backwards incompatible changes to the public 
> API require a major version bump, won’t I end up at version 42.0.0 
> very rapidly?//
> //
> //A: This is a question of responsible development and foresight. 
> Incompatible changes should not be introduced lightly to software that 
> has a lot of dependent code. The cost that must be incurred to upgrade 
> can be significant. Having to bump major versions to release 
> incompatible changes means you’ll think through the impact of your 
> changes, and evaluate the cost/benefit ratio involved./


In reality, we had two very successful minor releases after the release 
process was agreed: 5.5, and 5.6. I think 7.1 has bent the rules, and I 
think that's a shame.


> I don't like the thought that PHP 5.4
> could have been PHP 6 just because we removed safe_mode, that was
> deprecated in 5.3. That would be a disappointing reason just to go for
> a new major.

Agreed, so the answer would be not to remove it yet! If it was really 
that urgent to remove the feature, then yes, bump the version number to 
say so; if it could wait for one more minor release, then let it wait.

It's an odd example though, because for me by far the biggest break in 
5.4 was the removal of call-time pass-by-reference, which was widely 
used, and very fiddly to remove. But the story of 5.3 and 5.4 is 
inextricably tied up with the failure of 6.0, so we can come up with all 
sorts of "what if" scenarios and prove very little about the present and 
future.


> Same as above, I dislike this rapid jumping in versioning. Though this
> is my personal opinion, for me as a Core Developer of PHP, I prefer
> this scheme as it makes sense to me as it is pretty much what it
> always has been.

That's fine, that's what I mean by "version number as branding". But if 
we go down that route, we should drop all reference to major versions in 
our deprecation and compatibility policy, because that's a fundamentally 
different meaning of "major".

For instance, we could have a fixed duration of deprecation, say 
deprecated for 2 versions, removed in the next. So any features 
deprecated in 2017's release would be removed in 2019's release, 
regardless of its version number. In 2018, further features could be 
deprecated, to be removed in 2020, and so on.


>> That's why I mentioned divorcing the Engine and Language versions
> I don't think that will work as most people when you say the Zend
> Engine that is not into the PHP.net project will maybe know that its
> the core of PHP, but nothing more about it so I don't think it makes
> much sense to suddenly start label releases as such.

Sure, I was just brainstorming alternative solutions, since we seem to 
have very different ideas of what the version number is there for. 
Ignoring "Zend Engine" in particular, think about Windows prior to 10: 
the internal (kernel) version number had strict rules, and the marketers 
could make up whatever name they liked, meaning Windows 7 and 8 were 
both internally 6.x.


Regards,

-- 
Rowan Collins
[IMSoP]