On 19/11/2016 23:05, Kalle Sommer Nielsen wrote:
2016-11-19 22:56 GMT+01:00 Rowan Collins <rowan.coll...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
