On 19/11/2016 17:56, Marco Pivetta wrote:
On Sat, Nov 19, 2016 at 6:42 PM, Kalle Sommer Nielsen <ka...@php.net <mailto:ka...@php.net>> wrote:So to answer your question in a short without much more rambling: I think we should deprecate in x.z, then remove in x.z+1 depending on the feature, if we say "Oh let's remove this in the next major", chances are that major won't even be branches for years, and at that time, it could be forgotten.That will end up breaking the "expected" (because it's not that way anyway, but almost) SemVer approach, diminishing the trust from consumers in any kind of upgrade. Most of the current open-source libs out there are trying to push for SemVer - having PHP not following that seems like a huge mess to me.
I agree with this, to an extent. If we formally disavow any meaning of "major release" other than branding, the expectation is less of an issue in itself. But it's interesting that PostgreSQL is moving to a 2-part version numbering: instead of the annual feature releases being 9.7.0, 9.8.0, 9.9.0 etc, they will be 10.0, 11.0, 12.0, thus eliminating debate about which releases should be classed as "major".
Like you also mention, major versions are really rare and I think it should be kept that way, or at least until we reach a point where we literally cannot improve PHP7 anymore without major changes, such as the case for PHP 5.6 was.
What is a "major change", if you want to abandon the link to compatibility? Do you mean "headline-grabbing feature", i.e. versioning as a brand?
With our current model, that means that when we deprecate something, users got a year to upgrade their code, if they are bleeding edge users, but most are likely not, so they have more time to upgrade the code
This is a recipe for massive version fragmentation. When x.3 comes out, some people will be stuck on x.0, some on x.1, some on x.2, etc; library authors won't be able to take advantage of the features introduced in x.3, and everyone has to remember just what's new in each release.
I actually think major releases should be *more* common, to reduce the temptation to "bend" the rules, and break compatibility early. The policy could be as simple as "every major release will have between 3 and 5 minor releases". Then the earliest release of 8.0 would be after 7.2 (late 2018 / early 2019), and the latest would be after 7.4 (late 2020 / early 2021).
Having a road map in advance also means you can branch early, break things, and know how long you're going to have to maintain that branch for.
Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
