Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70363
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
Message-ID: <52927B28.9050609@gmail.com>
Date: Sun, 24 Nov 2013 22:18:16 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAF+90c_zyAr7kRnY9FArehhJ-QUxA-6B4TqNUx2Bzxwumbr1zA@mail.gmail.com> <CAH-PCH7k_OuxCyhGsUYcX4Nd7SFLQK3r7squpSkKMo=znyO3aA@mail.gmail.com> <CAMUwpuQiOFv_+A8bWmKUW8qrbWjpJOOxmZ5LP0kFjrBE2jbw1Q@mail.gmail.com>
In-Reply-To: <CAMUwpuQiOFv_+A8bWmKUW8qrbWjpJOOxmZ5LP0kFjrBE2jbw1Q@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Making "backwards compatibility" discussions more constructive
From: rowan.collins@gmail.com (Rowan Collins)

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]