Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70366
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.173 as permitted sender)
Message-ID: <52928F7A.1010801@gmail.com>
Date: Sun, 24 Nov 2013 23:44:58 +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> <52927B28.9050609@gmail.com> <529286CA.9040805@ajf.me>
In-Reply-To: <529286CA.9040805@ajf.me>
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 24/11/2013 23:07, Andrea Faulds wrote:
>
>
> On 24/11/13 22:18, Rowan Collins wrote:
>> 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.
>
> How about we collect various features that unfortunately break 
> backwards-compatibility in a branch, and then eventually release 6.0 
> once a world-shattering feature comes along?
>

That seems to be the current approach, but it has some real drawbacks:

- people don't want to spend time on such features if they're just going 
to be left hanging around on a branch for years
- it adds extra effort maintaining such a branch in the face of other 
features which *do* make it into releases, but end up touching the same code
- it's not particularly helpful for users if the number of features 
marked "deprecated" continues to grow, but nobody can say when they'll 
actually be removed, and thus whether we should really care any more 
than we do about "strict standards"

More fundamentally, it assumes that a world-shattering feature will 
somehow "come along" from Somewhere Outside, rather than it being 
something that you all (it seems presumptuous to include myself in a 
"we") need to actively choose to do.

Why do you think now is not the moment to start planning a major 
release? That's not an accusation, I'm genuinely interested in your 
answer (and anyone else's):

- Is there an absolute timescale you would like to wait for 5.x to 
mature? Then let's discuss that timescale.
- Do you not feel there's enough will or talent to drive the project 
beyond modest goals? What should be done to improve that?
- Do you think there are no ideas floating around that would be worthy 
of a major release? I'm sure we could brainstorm plenty; I have half a 
dozen floating around my head, with varying chances of catching on...
- Do you just think that actually the language is Good Enough, and we 
should just carry on refining 5.x for the foreseeable future? In which 
case,  deprecation notices, and unreleased features committed to master, 
are kind of pointless.

If people don't think now is the right time to plan PHP 5+1, that's fine 
by me; but I think it would be useful to have a line of reasoning, which 
could be tested in future for other values of "now".

-- 
Rowan Collins
[IMSoP]