Re: Making "backwards compatibility" discussions more constructive
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]
Thread (16 messages)