On Mon, Jun 13, 2016 at 9:07 AM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> On 06/06/2016 08:22, Dmitry Stogov wrote: > >> >> This mini RFC has been moved to "Voting" state. Voting >> began on Jun 6 and will close on June 16. >> >> You can find the full RFC at: https://wiki.php.net/rfc/too_few_args >> >> > The more I think about this RFC, the less I agree with it being included > in 7.1. > > I realise this is now officially late in the approval process to raise > these points, but note that the discussion period was just 5 days, when a > language change would normally require 2 weeks. > > <snip> > > There is an assumption from those who have spoken in favour of the RFC > that such warnings will rarely be ignored in real world code, and therefore > nobody will actually be affected by this. Here, we are pitching anecdote > against anecdote; my feeling is that many people routinely ignore warnings, > and will consider their code to be "running fine" under 7.0, then see it > "crash" under 7.1. > I was pleased when the "minor versions will retain BC" policy was adopted, > because I thought it would avoid the problems we had with PHP 5.3 and 5.4, > and allow wider adoption of the latest version. Allowing this change would > mean that promise has been broken. > Rowan, spot on. We're breaking promises, *when we don't need to: *just accelerate releases of major versions. In my mind, a version makes a concise statement about what changes to expect. It's like a changelog, but with less reading. But that only works when the major, minor, and patch numbers have stable meanings. I would rather see us establish and hold firm on the membership rules (what kind of change can go in what version) and quickly release queued implementations, than destabilize the meaning of version numbers. For example, our promise might read like: "Patches do not change the language. Minors may *add* non-breaking language features. Majors may *change* language features. Releases will be made as soon as there is a critical mass of queued implementations." What's in a release, when a release goes out, and when it's no longer maintained is all arbitrary. Amidst all this arbitrariness, let's at least give our users version numbers with reliable meaning. bishop
