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. 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 ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
