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