> -----Original Message-----
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Sunday, July 06, 2014 2:19 AM
> To: Zeev Suraski
> Cc: PHP
> Subject: Re: [PHP-DEV] [RFC] Name of Next Release of PHP
>
>
> On 6 Jul 2014, at 00:05, Zeev Suraski <z...@zend.com> wrote:
>
> > I think there's some confusion here.
> >
> > If the next version of PHP is going to be a major one (which is
> > clearly defined in https://wiki.php.net/rfc/releaseprocess), then I
> > believe the only two options that were ever raised are PHP 6 and PHP
> > 7.  If you're aware of other proposals that were made then please
> > state them, otherwise, I think it's a very clear decision between 6
> > and 7 - and putting this as a 'yes/no' for 6 gives it undue advantage.
>
> Well, if we have the current yes/no to PHP 6 vote, then if it passes, we
get
> PHP 6. If it doesn't pass, we're back where we were before.
>
> If we go for PHP 6/PHP 7 vote, then the result is unclear. Would one
option
> be the default? Would it be PHP 7 if it's not PHP 6? Would it be PHP 6
if it's
> not PHP 7? In which case, what's the point in a majority? We could hold
a
> 50%+1 vote, but such a vote would be contentious and would be a
popularity
> contest, not requiring consensus. If we don't have a default, and either
6 has
> to get 2/3 or 7 has to get 2/3, then we should have an Other option, or
a
> Continue Discussion option, or both. This is all way too complicated for
me and
> I don't want the vote to be contentious or confusing.

I'll simply repeat what you already quoted:

"If the next version of PHP is going to be a major one (which is clearly
defined in https://wiki.php.net/rfc/releaseprocess), then I believe the
only two options that were ever raised are PHP 6 and PHP 7."

Yes, it'll be 7 if it's not 6;  It'll be 6 if it's not 7.  Nobody proposed
a new versioning scheme and the only reason there is a discussion in the
first place is because many people, myself included, are proposing that we
skip version 6 - for a variety of reasons (the least of which is books on
Amazon).

The choice should be between them.  Between skipping or not skipping.
Putting such a biased RFC is lot more contentious as it actively ignores
what many people think - not through oversight, but through insistence to
avoid putting up the other option there. Ultimately, we need to make a
choice between these two options, and the current RFC goes a long way to
hide that fact and deny those who believe in the 2nd option to have their
opinion count.

> Which options? 6 and 7? This isn't a 6 vs 7 RFC. This is a 6 or not RFC.

This RFC makes no sense in its current context.  Insisting on keeping it a
'6 or nothing' ignores the elephant in the room - that there *IS* just one
other option and that option is 7 (again, all of that in the fairly safe
assumption that the next version will be a major one per the
releaseprocess RFC).  Do we really want to go down the route of
kindergarten and spin up a 'competing' 'PHP 7 or nothing' RFC?

> Sure, I can't make a great case against 6, unfortunately. I am willing
to accept
> suggestions here.

A good start would be reviewing the threads that discussed it already.
They had plenty of reasons on why 'PHP 6' is a bad idea that had nothing
to do with books or Amazon or authors. I mentioned the thread name is
'About PHP6 ...'.

> The entire point of this RFC is to get the discussion over with sooner
rather
> than later, and hopefully come to a decision quickly so we don't need to
> discuss it again.
>
> Also, I disagree that holding a vote to settle the name matter once and
for all
> is a waste of energy. It should, hopefully, mean less energy wasted than
> otherwise in future.

I think you're getting into it thinking we can just swiftly decide that
it's going to be PHP 6 and be done with it.  We can't.  Probably same for
7.  There'll be a lot of heated debates, and a lot of energy will go into
that.  I believe that energy will be much better spent in other fronts at
this point in time.
But it's even more than that.  Your insistence to stick to a '6 or
nothing' approach has a fair chance of getting us into a situation where
we agree to disagree so that we can all revisit this hot potato sometime
later in the future, and waste yet some more energy about it.  Quoting
your initial email:

"Should it fail, nothing is really lost, except that the discussion will
inevitably resurface at some point."

This is the exactly opposite of 'once and for all', and means that this
energy could end up being completely wasted.  If you *truly* want to
settle this once and for all, it needs to have two definite options and
not one definite and one open ended option.

The way I see it, the available courses of action rated according to my
subjective preference:

1. Shelf this until a later time when we actually have a better idea about
what php.next is and have spent some more time actually creating it
(seriously considering putting up an RFC for that ;)
2. Stick with it, but change the RFC to reflect both camps' opinions and
make it definite, so that we don't need to revisit this again in the
future
3. Stick with the (IMHO very weird) "PHP 6 or nothing" RFC, and perhaps
spin up another "PHP 7 or nothing" RFC.

That last option is pretty ridiculous IMHO.  What happens if neither
option gets 2/3?  Or maybe both?  There's just no way to choose between
two options in the table while pretending one of them doesn't exist.

Zeev

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to