Re: Making "backwards compatibility" discussions more constructive

On 20/11/2013 11:41, Ferenc Kovacs wrote:

Personally I think that our current release process RFC only solves half of the problem. We were seeing slow adoption rates for new versions and also users complaining about every second micro version breaking backward compatibility (some of those concerns were ofc. magnified), but having the current release process, which promises complying with the current best practices, aka semantic versioning (http://semver.org/). Then, on 21/11/2013 10:59, Julien Pauli wrote:

I agree that we keep telling people "no no I don't want to merge your patch as it breaks BC", but we have no idea as when we'll release a new major , so that all those little patches can show up. I agree with Ferenc, saying that we need to plan major releases. For example, for 5.6 , we could also have branched a major, aka, a 6.0 , and break lots of things, like cleaning the INI settings like Yasuo says in a reply to this topic.

As somebody fairly new to the community (as opposed to the language) I'd like to lend my support to this line of reasoning. Semantic Versioning is good at saying what should *not* be in a *minor* release, but doesn't really say what *should* be in a *major* release - that is a question of vision and ambition. If you'll excuse the pun, I think the "elephpant in the room" here is the failure of the PHP 6 Unicode project. Abandoning that work was probably the right decision, and the choice of features in 5.3 and 5.4 flowed naturally from that decision, but it has had a couple of unfortunate effects: - Declaring that all 5.x releases *after* 5.4 are to be backwards compatible is a bit like making a New Year's Resolution in June: it is a perfectly sound aim, but it all sounds a bit fuzzy when you try to explain it. - There is a general unease at the idea of launching a PHP 6.0 into the world - not an unusual thing, as I noted in an old blog post on "The Golden Rules of Version Naming" [1] - but particularly acute having failed on the previous attempt. PHP 5.3 was branched over 6 years ago [2] and the PHP 6 Unicode implementation officially abandoned 3.5 years ago [3]; contrast that with the 6 years between PHP 4.0 and PHP 5.0 (and only 5 years between the radically different PHP 1.0 and 4.0!), and the current limit of 3 years for support of new releases. Time, as the self-help books would say, to seek closure and move on. The feeling in the air at the moment seems to be that in order for PHP to move beyond 5.x there would need to be some bold, world-shattering feature, to replace the Unicode work. Yet features are proposed and abandoned because they are too big a change for a minor release, but somehow not enough to justify a major release. There are two solutions to that (which aren't necessarily mutually exclusive): a) Choose a bold, world-shattering feature, and rally the troops. There are plenty of things that could be considered here, but I'll leave my musing on those for elsewhere. b) Declare that, just as minor versions now happen every year, major versions will happen on a regular basis, whether or not the language has radically changed, to allow the evolution of the language to proceed without maintaining an ever-growing list of deprecated quirks. If PHP is to remain relevant to the world, it needs two things: it needs to give users time to catch up, as the current release process does for minor versions; but it also needs to give those developing the language itself a chance to improve it with modern, well-designed features. Well, that's my two $minor_currency_units anyway. [1] http://rwec.co.uk/q/versions [2] http://news.php.net/php.internals/32451 [3] http://news.php.net/php.internals/47120 -- Rowan Collins [IMSoP]