Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97080
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.66 as permitted sender)
MIME-Version: 1.0
Sender: kalle.php@gmail.com
In-Reply-To: <3dc880ba-3a40-1927-62f6-32a2e2b2143f@gmail.com>
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>
Date: Sun, 20 Nov 2016 00:05:10 +0100
Message-ID: <CAJW__o2mp5uwBLbSkMg7dCOz3x5Jj7YjUCk3fD1A+RUbD6H7iA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.2
From: kalle@php.net (Kalle Sommer Nielsen)

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. 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, which is
both good and bad, then a new x+1.z or x.z+1 version was based off
having a large number of features that branded that version as a
whole, and I think that is perfectly fine.

> 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 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. 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.

I think the main reason we reserve major versions, and have in the
past is that the internal API is very compatible across minor
versions, 5.x even contained macros for PHP4 extensions to be mostly
compatible or even loadable pre 4.3 extensions for a long time if I
remember correctly (I think it was Julien that removed that in 5.5).

> 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.

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. Taking Chrome, or well Blink as I use Opera, as an
example, I don't see the big point in that every few weeks I get a new
major version of my browser because some handy new feature was added,
might as well have been a minor release, like Opera used to be in the
Presto days.

>
> 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.

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. PHP for almost
two decades have only been released with Zend Engine and they are so
coupled together today that I doubt you can build LibZend standalone
anymore.


-- 
regards,

Kalle Sommer Nielsen
kalle@php.net