Good evening,
I am announcing a rather unorthodox RFC.
With the advent of the phpng and uniform variable syntax RFCs, it looks likely the next major release of PHP, to succeed the 5.x series, may appear relatively soon. However, unlike with previous releases of PHP, it is not entirely clear what it shall be called.
This RFC attempts to settle the matter once and for all with a straight yes/no vote as to whether the name should be PHP 6. Should it pass, the matter is settled and we actually have a proper name for this fabled “PHP NEXT”. Should it fail, nothing is really lost, except that the discussion will inevitably resurface at some point. The plan, really, is to hopefully get it over with now so we don’t have to have this discussion later, avoiding potential future bikeshedding or derailment.
This is the shortest RFC I’ve ever authored, and I’d greatly appreciate it if everyone read the whole thing:
The plan for voting, if I think we should go ahead with it, is the same as a normal RFC: at least 2 weeks after proposed to internals, voting for at least 1 week.
Thanks!
Andrea Faulds
http://ajf.me/
Andrea,
While I'm not sure whether this isn't a bit premature to have this
discussion, if we were to have this discussion, the RFC should do a much
better job at summarizing the discussions we already had in the past.
First, it shouldn't be a yes/no for PHP 6, but rather, a 'PHP 6, PHP 7, or
Defer Decision' or at least 'PHP 6 / PHP 7'.
Secondly, contrary to what the RFC implies, the reasons against using
version 6 went far beyond books - and covered much more important things
(honestly I never quite understood the preoccupation with this books
angle, I don't think anybody at all cares about it). If we decide to do
the discussion now, the RFC should cover them (they were discussed in a
thread named "About PHP6 ..."
Third, numerous people (myself included) actively proposed we skip version
6 and go with version 7; Dismissing that with "I don't think the
alternative naming options are really much better" doesn't seem to belong
in an RFC. The merits of this option - which were really more about the
drawbacks of calling it '6' and the lack of drawbacks of calling it '7'
should be properly described in the RFC.
Of course, you don't have to buy into that reasoning, but let's not tuck
the discussion away under the carpet. If we were to have this discussion
now, let's make the best cases we can for both options on the table,
instead of focusing on just one and dismissing the opposition as something
about books.
Another couple of cents - both because of what I said here but also
unrelated, I think /rfc/php6 is a bad name for this RFC (both because
there's more than one option, but also because this is too generic for
something as wide as the next version of PHP). Perhaps /rfc/php2015 is a
better choice, or at least /rfc/php.next.name
Thanks! :)
Zeev
-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Sunday, July 06, 2014 12:24 AM
To: PHP
Subject: [PHP-DEV] [RFC] Name of Next Release of PHPGood evening,
I am announcing a rather unorthodox RFC.
With the advent of the phpng and uniform variable syntax RFCs, it looks
likely
the next major release of PHP, to succeed the 5.x series, may appear
relatively soon. However, unlike with previous releases of PHP, it is
not
entirely clear what it shall be called.This RFC attempts to settle the matter once and for all with a straight
yes/no
vote as to whether the name should be PHP 6. Should it pass, the matter
is
settled and we actually have a proper name for this fabled "PHP NEXT".
Should
it fail, nothing is really lost, except that the discussion will
inevitably resurface
at some point. The plan, really, is to hopefully get it over with now so
we don't
have to have this discussion later, avoiding potential future
bikeshedding or
derailment.This is the shortest RFC I've ever authored, and I'd greatly appreciate
it if
everyone read the whole thing:The plan for voting, if I think we should go ahead with it, is the same
as a
normal RFC: at least 2 weeks after proposed to internals, voting for at
least 1
week.Thanks!
Andrea Faulds
http://ajf.me/--
To unsubscribe,
visit:
http://www.php.net/unsub.php
While I'm not sure whether this isn't a bit premature to have this
discussion, if we were to have this discussion, the RFC should do a much
better job at summarizing the discussions we already had in the past.
That’s true. I’ve updated it with more arguments from past discussions.
First, it shouldn't be a yes/no for PHP 6, but rather, a 'PHP 6, PHP 7, or
Defer Decision' or at least 'PHP 6 / PHP 7’.
I don’t want to have a vote with over two choices, I don’t think it would be fair (one option could pass without >50% voting for it), and a binary 6/7 choice is forcing people’s hand. I want it to be simple and straightforward, so that is why it is Yes or No to PHP 6. If people vote no, there could always be a different vote later, but that is not what I want to do.
I am not going to change the vote options.
Secondly, contrary to what the RFC implies, the reasons against using
version 6 went far beyond books - and covered much more important things
(honestly I never quite understood the preoccupation with this books
angle, I don't think anybody at all cares about it). If we decide to do
the discussion now, the RFC should cover them (they were discussed in a
thread named "About PHP6 ..."Third, numerous people (myself included) actively proposed we skip version
6 and go with version 7; Dismissing that with "I don't think the
alternative naming options are really much better" doesn't seem to belong
in an RFC. The merits of this option - which were really more about the
drawbacks of calling it '6' and the lack of drawbacks of calling it '7'
should be properly described in the RFC.
I’ve covered the PHP 7 issue more now.
Of course, you don't have to buy into that reasoning, but let's not tuck
the discussion away under the carpet. If we were to have this discussion
now, let's make the best cases we can for both options on the table,
instead of focusing on just one and dismissing the opposition as something
about books.
Sure.
Another couple of cents - both because of what I said here but also
unrelated, I think /rfc/php6 is a bad name for this RFC (both because
there's more than one option, but also because this is too generic for
something as wide as the next version of PHP). Perhaps /rfc/php2015 is a
better choice, or at least /rfc/php.next.name
Right, the URL isn’t entirely ideal, but it’s not really important. I don’t think it’s possible to change it, and this is at least memorable. Really, RFC URLs are pretty meaningless. We’ve had URLs before with spelling errors in them.
Thanks.
Andrea Faulds
http://ajf.me/
I don't want to have a vote with over two choices, I don't think it
would be fair
(one option could pass without >50% voting for it), and a binary 6/7
choice is
forcing people's hand. I want it to be simple and straightforward, so
that is why
it is Yes or No to PHP 6. If people vote no, there could always be a
different
vote later, but that is not what I want to do.
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.
If it's not going to be a major version, then we're talking about PHP 5.7
and there's no reason for this discussion in the first place.
Really, the only decision on the table is "what do we call the next
version of PHP if it's a major one", and the two options on the table are
'6' and '7'. That is, assuming we decide there is a decision to be made
on the table to begin with.
I've covered the PHP 7 issue more now.
Not really, not in a meaningful way. You haven't covered the real
drawbacks of calling it PHP 6 (it's still this books thing which nobody
cares about, and perhaps even incites people to support 6 just to spite
these 'evil book authors'), and you haven't covered the advantages or
disadvantages of calling it 7 - beyond a very weak and very biased
dismissal. I'm intentionally not going into those here, because I don't
want to (re)start the discussion right here and now. A lot has been said
already about this and the RFC should reflect it, or not move ahead.
Of course, you don't have to buy into that reasoning, but let's not
tuck the discussion away under the carpet. If we were to have this
discussion now, let's make the best cases we can for both options on
the table, instead of focusing on just one and dismissing the
opposition as something about books.Sure.
Andrea - this updated RFC is the very definition of tucking the discussion
under the carpet and trying to run ahead to force a 6 decision without
doing the discussion that already took place any justice.
The only way to really make the case for both options is for someone who
believes in each option to make the case; And to make this RFC about a
decision between these two. You may be the one for 6 but you're clearly
not the one for 7; I could be that someone if this can wait for later in
July (and I see no reason why it couldn't).
However, I have to say I wish that instead of (IMHO) wasting energy on
such a discussion at this point, we'd focus on the actual content of
php.next. People sharing phpng benchmarks and testing it with their apps
would be a whole lot more productive use of our time.
Zeev
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.
Hence, it is a Yes/No vote to PHP 6. If it fails, we are back to where we were before. If it passes, the name is PHP 6. It could not be more straightforward, and the result cannot be misinterpreted. It requires a 2/3 majority to pass, so it would require consensus. Again, this is my position and I am sticking to it. I see no good reason to complicate matters.
I've covered the PHP 7 issue more now.
Not really, not in a meaningful way. You haven't covered the real
drawbacks of calling it PHP 6 (it's still this books thing which nobody
cares about, and perhaps even incites people to support 6 just to spite
these 'evil book authors'), and you haven't covered the advantages or
disadvantages of calling it 7 - beyond a very weak and very biased
dismissal. I'm intentionally not going into those here, because I don't
want to (re)start the discussion right here and now. A lot has been said
already about this and the RFC should reflect it, or not move ahead.
I’m willing to take suggestions, if that could improve it.
Andrea - this updated RFC is the very definition of tucking the discussion
under the carpet and trying to run ahead to force a 6 decision without
doing the discussion that already took place any justice.The only way to really make the case for both options is for someone who
believes in each option to make the case; And to make this RFC about a
decision between these two.
Which options? 6 and 7? This isn’t a 6 vs 7 RFC. This is a 6 or not RFC.
Sure, I can’t make a great case against 6, unfortunately. I am willing to accept suggestions here.
However, I have to say I wish that instead of (IMHO) wasting energy on
such a discussion at this point, we'd focus on the actual content of
php.next. People sharing phpng benchmarks and testing it with their apps
would be a whole lot more productive use of our time.
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.
Andrea Faulds
http://ajf.me/
-----Original Message-----
From: Andrea Faulds [mailto:ajf@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 PHPI 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
- 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
- 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:
- 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 ;) - 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 - 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
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.Hence, it is a Yes/No vote to PHP 6. If it fails, we are back to where we
were before. If it passes, the name is PHP 6. It could not be more
straightforward, and the result cannot be misinterpreted. It requires a 2/3
majority to pass, so it would require consensus. Again, this is my position
and I am sticking to it. I see no good reason to complicate matters.
I tend to agree. PHP 6 is the next increment. The question is whether we
should continue following that standard or break from it for the reasons
raised in the previous thread. If we break from it, then we'd have to
decide what the next version name would be. However, based on the results
of the previous thread on this matter, it seems extremely unlikely that the
vote wouldn't be yes for PHP 6, so I don't think there's any pressing need
to expand the scope of this vote beyond that. We should first establish
whether or not we're sticking with the current conventions and going with
PHP 6. If the vote is in favor of going another route, we can then put
together a new RFC to figure out what the new convention should be (whether
to arbitrarily skip a version increment or do away with the incremental
number entirely and go with something else, like "PHP <year>" or "PHP
<name>").
I certainly wouldn't agree that 7 is the only other option. Personally, my
vote would be to keep the current naming convention and not skip 6. But if
the outcome goes the other way, my preference would be to break from the
incremental number system altogether because that'd be less confusing than
an arbitrary skip, so it'd make more sense to be able to vote on that when
and if people vote to discontinue the current naming convention and not go
with the next increment of 6.
--Kris
I would, however, recommend that Andrea take Zeev's input and create a more
comprehensive section outlining his arguments in favor of breaking from the
current convention. Another section could be created to outline the other
side. What we don't want is a situation where Zeev feels compelled to
write a competing RFC. That could get messy, so I think it'd be best if
the two of you could find enough common ground to make this RFC acceptable
to both sides.
I'd also recommend that, since you're calling for a 2/3 vote, you specify
more clearly what it is that requires 2/3; breaking the current convention
or keeping the current convention? I'm guessing you probably meant the
former, but the wording seemed a bit vague on that point to me.
--Kris
I would, however, recommend that Andrea take Zeev's input and create a more comprehensive section outlining his arguments in favor of breaking from the current convention. Another section could be created to outline the other side. What we don't want is a situation where Zeev feels compelled to write a competing RFC. That could get messy, so I think it'd be best if the two of you could find enough common ground to make this RFC acceptable to both sides.
Right. As I said, I’m willing to improve the Rationale section with suggestions, I just can’t think of many other arguments for at the moment. Perhaps I need to delve deeper and read some more previous discussions. I’m not in favour of the version skip, and though I can play devil’s advocate, I am not really very good at doing so here. I don’t dispute that the Rationale section could do with improvement.
I'd also recommend that, since you're calling for a 2/3 vote, you specify more clearly what it is that requires 2/3; breaking the current convention or keeping the current convention? I'm guessing you probably meant the former, but the wording seemed a bit vague on that point to me.
I’m not exactly sure what you’re talking about here, but to clarify: It is a 2/3 majority-required vote on whether or not the name should be PHP 6. That would be in line with the current convention of incrementing the major version number.
I can see Zeev’s point that 7 is the main other option (though I also think 6.1, or codenames, are possible though unlikely other options). However, I don’t want to call a 50%+1 6/7 vote because it just feels like too narrow of a majority. I suppose if that 6 yes/no vote fails, I might consider a 50%+1 6/7 vote.
Bear in mind I proposed at some point recently that we use 2/3 for all votes. That was largely related to the 64bit RFC, but I still agree with the principle.
To be honest, I may end up retreating at this point and just calling a 50%+1 before even running a 2/3 one. My problem with that is that I feel such a narrow majority would be too contentious and not end the discussion for good.
Sadly, it is not realistic to hold a vote on the majority with which to vote. ;)
--
Andrea Faulds
http://ajf.me/
I would, however, recommend that Andrea take Zeev's input and create a
more comprehensive section outlining his arguments in favor of breaking
from the current convention. Another section could be created to outline
the other side. What we don't want is a situation where Zeev feels
compelled to write a competing RFC. That could get messy, so I think it'd
be best if the two of you could find enough common ground to make this RFC
acceptable to both sides.Right. As I said, I’m willing to improve the Rationale section with
suggestions, I just can’t think of many other arguments for at the moment.
Perhaps I need to delve deeper and read some more previous discussions. I’m
not in favour of the version skip, and though I can play devil’s advocate,
I am not really very good at doing so here. I don’t dispute that the
Rationale section could do with improvement.I'd also recommend that, since you're calling for a 2/3 vote, you
specify more clearly what it is that requires 2/3; breaking the current
convention or keeping the current convention? I'm guessing you probably
meant the former, but the wording seemed a bit vague on that point to me.I’m not exactly sure what you’re talking about here, but to clarify: It is
a 2/3 majority-required vote on whether or not the name should be PHP 6.
That would be in line with the current convention of incrementing the major
version number.
That's exactly my point; i.e. "2/3.... whether or not" seems ambiguous to
me. Does that mean that a 2/3 "yes" vote is required for the version to be
PHP 6? Or does it mean that a 2/3 "no" vote is required for the version
not to be PHP 6?
--Kris
I want to point out that neither options (6 nor 7) break the our
convention. PHP 6 was a live project that was worked on by many people,
and known as such by many many more; Even though it never reached GA –
there was definitely software named PHP 6. Whether reusing that version
number for something completely different several years later constitutes
breaking the current convention or applying it to reality it is open for
interpretation. I also suggest we don’t go in the direction of the 2/3
interpretation – as I pointed out in the past this places undue power in
the hands of the RFC author and his interpretation of the voting RFC (which
absolutely needs to be amended to fix that). That’s yet another reason on
why the vote should be between 6 or 7 so that problem goes away completely
– it becomes a clear choice that will have result in a clear cut decision.
If we keep it as a ‘PHP 6 or nada’ there’s a fair chance I’ll write an
alternative RFC, most probably not a ‘7 or nada’ but the much more fair ‘6
or 7’ RFC. From the beginning, people who believed there was a problem
with using PHP 6 said we should skip a version, and not move to 6.1 or
change our versioning scheme. It was only those who opposed it (i.e. those
who believed we should go with 6) that brought up alternative ideas – but
really wanted to stick with 6. Judging from what you said, if you had 3
options, 6, 7 or change_versioning_scheme, you’d pick the first option, not
the last. From the discussion we had on internals – nobody’s first choice
was that change_versioning_scheme option, it was either 6 or 7, stick or
skip. That’s why it makes absolute sense to have these as the two options
available for voting.
If 7 gets chosen and you end up feeling that it’s so horrendous we need to
change our entire versioning scheme, you’d of course have the option of
proposing another versioning scheme and convince people to vote for it…
But right now, you’re adding options which are both completely outside the
realm of our versioning scheme, AND aren’t what you’d vote for anyway –
just to avoid having the real other option that’s on the table be a valid
choice for voting.
I still absolutely think we should bury this until later in the project’s
lifecycle as our energy right now is probably much better spent
elsewhere.
Zeev
From: Kris Craig [mailto:kris.craig@gmail.com]
Sent: Sunday, July 06, 2014 3:29 AM
To: Andrea Faulds
Cc: Zeev Suraski; PHP
Subject: Re: [PHP-DEV] [RFC] Name of Next Release of PHP
I would, however, recommend that Andrea take Zeev's input and create a more
comprehensive section outlining his arguments in favor of breaking from the
current convention. Another section could be created to outline the other
side. What we don't want is a situation where Zeev feels compelled to
write a competing RFC. That could get messy, so I think it'd be best if
the two of you could find enough common ground to make this RFC acceptable
to both sides.
I'd also recommend that, since you're calling for a 2/3 vote, you specify
more clearly what it is that requires 2/3; breaking the current convention
or keeping the current convention? I'm guessing you probably meant the
former, but the wording seemed a bit vague on that point to me.
--Kris
I still absolutely think we should bury this until later in the project’s
lifecycle as our energy right now is probably much better spent
elsewhere.
The problem with that statement is just how do you identify what
material one is looking at relates to the 'current' PHPNext?
My only argument for not using 'PHP6' is simply that there is a
substantial volume of material, printed and otherwise, related to all
the discussions on PHP6. We now have discussion on phpng which ring
fences that particular development fork, and phpnext is also being used,
but using that then creates a problem with next+1. As with windows
development with branches like NT and Vista, strict adherence to a
number sequence is not essential, but we need some cleanly identifiable
tag for the current 'next' discussions simply to remove the dross?
IS phpng a fore gone conclusion as the base of phpnext? So has this
debate already been decided and are we now working on phpng only anyway?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi,
Le 06/07/2014 03:13, Zeev Suraski a écrit :
I want to point out that neither options (6 nor 7) break the our
convention. PHP 6 was a live project that was worked on by many people,
and known as such by many many more; Even though it never reached GA –
there was definitely software named PHP 6. Whether reusing that version
number for something completely different several years later constitutes
breaking the current convention or applying it to reality it is open for
interpretation. I also suggest we don’t go in the direction of the 2/3
interpretation – as I pointed out in the past this places undue power in
the hands of the RFC author and his interpretation of the voting RFC (which
absolutely needs to be amended to fix that). That’s yet another reason on
why the vote should be between 6 or 7 so that problem goes away completely
– it becomes a clear choice that will have result in a clear cut decision.
It's my first post in this list, and wanted to share my external point
of view, with a parallel with the MySQL world.
MySQL 6 was alpha in 2007 and finally was never released.
So far its name has never been reused (instead we had MySQL 5.6 and 5.7
to avoid confusion, and there are also books about PHP 6 / MySQL 6)
Even on the MariaDB side, they bumped up the version to 10.0 to avoid
confusion (and because it was not based on MySQL 5.6).
There are quite a few tutorials and reference about PHP 6 on the web, it
would be misleading to have something completely different, but with the
same name as the "old" PHP 6. However I'm not convinced "7" is the right
choice, perhaps a radical change in version number would be better ?
--
Jocelyn Fournier
It's my first post in this list, and wanted to share my external point of view, with a parallel with the MySQL world.
Welcome to PHP! :)
MySQL 6 was alpha in 2007 and finally was never released.
So far its name has never been reused (instead we had MySQL 5.6 and 5.7 to avoid confusion, and there are also books about PHP 6 / MySQL 6)
Even on the MariaDB side, they bumped up the version to 10.0 to avoid confusion (and because it was not based on MySQL 5.6).
Similarly, ECMAScript 4, which was to be the replacement for ECMAScript 3, was abandoned and skipped, with ECMAScript 5 replacing it and ECMAScript 6/Harmony continuing it in spirit. There is some precedent for this.
There are quite a few tutorials and reference about PHP 6 on the web, it would be misleading to have something completely different, but with the same name as the "old" PHP 6. However I'm not convinced "7" is the right choice, perhaps a radical change in version number would be better ?
Well, 7 is a nice number. But yes, a more radical change might be better. How about PHP 14, after the year? PHP Loxodonta, a genus of elephants? PHP 14.mm, where mm is the month, following the Ubuntu month/year scheme?
However, all other options only seem to have fringe support at the moment, so a binary 6/7 vote is optimal, unless you can find a name everyone can agree on. Keeping with 6 or 7 means we stick to our tried and tested naming scheme, too. I think that’d be for the best.
Side note: another thought comes to me now that just skipping 6 and going to 7 makes little sense in a way, as 7 isn’t the successor to 6, it is the second successor to 5, the first (the old PHP 6) having been abandoned.
Andrea Faulds
http://ajf.me/
hi,
While I'm not sure whether this isn't a bit premature to have this
discussion, if we were to have this discussion, the RFC should do a much
better job at summarizing the discussions we already had in the past.
I think it is not premature but also totally not important, but a
matter of priorities I suppose...
First, it shouldn't be a yes/no for PHP 6, but rather, a 'PHP 6, PHP 7, or
Defer Decision' or at least 'PHP 6 / PHP 7'.
Agree here, while my oppinion is clearly for 6, which is the next
major version after 5, last time I checked. But as you said, no need
to re do the discussions.
Another couple of cents - both because of what I said here but also
unrelated, I think /rfc/php6 is a bad name for this RFC (both because
there's more than one option, but also because this is too generic for
something as wide as the next version of PHP). Perhaps /rfc/php2015 is a
better choice,
I seriously hope that you take 2015 as pure example here. As I see no
remote chance to be ready next year. PHPNG is a huge stack of
undocumented perf patches far from being ready, APIs &code cleanup did
not even begin, and the existing APIs are even more ugly. This is not
going to be a small task, besides other things that we may like to
have in the next major version. A 2 years development period sounds
much more realistic to me.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
I seriously hope that you take 2015 as pure example here. As I see no
remote chance to be ready next year. PHPNG is a huge stack of
undocumented perf patches far from being ready, APIs &code cleanup did
not even begin, and the existing APIs are even more ugly. This is not
going to be a small task, besides other things that we may like to
have in the next major version. A 2 years development period sounds
much more realistic to me.
I’m perhaps a little bit optimistic. ;)
But yes. 2015 was just the earliest possible year that PHP NEXT could happen, though 2016 is probably more realistic.
--
Andrea Faulds
http://ajf.me/
I seriously hope that you take 2015 as pure example here. As I see no
remote chance to be ready next year. PHPNG is a huge stack of
undocumented perf patches far from being ready, APIs &code cleanup did
not even begin, and the existing APIs are even more ugly. This is not
going to be a small task, besides other things that we may like to
have in the next major version. A 2 years development period sounds
much more realistic to me.
If that is a realistic roadmap, then what also needs to be added is just
what happens with the PHP5 in the meantime. From my own view, some
elements of 'PHP6' are still overdue, but if it will be yet another
couple of years then should we be looking at an interim solution for
'bigint' and unicode? While reworking the entire code base to give a
performance improvement is a perfectly sensible long term plan it
sidesteps the 'problems' that PHPNext should ideally address. There are
perhaps two conflicting paths here?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
I seriously hope that you take 2015 as pure example here. As I see no
remote chance to be ready next year. PHPNG is a huge stack of
undocumented perf patches far from being ready, APIs &code cleanup did
not even begin, and the existing APIs are even more ugly. This is not
going to be a small task, besides other things that we may like to
have in the next major version. A 2 years development period sounds
much more realistic to me.If that is a realistic roadmap, then what also needs to be added is just
what happens with the PHP5 in the meantime. From my own view, some
elements of 'PHP6' are still overdue, but if it will be yet another
couple of years then should we be looking at an interim solution for
'bigint' and unicode? While reworking the entire code base to give a
performance improvement is a perfectly sensible long term plan it
sidesteps the 'problems' that PHPNext should ideally address. There are
perhaps two conflicting paths here?
I am skeptical on bigint in the engine given what is possible now in
gmp. But yes, phpng is also a problem as it creates a total new code
base and barely blocks any other improvements. Why? Except that bigint
thing, I do not see many people trying to add stuff based on phpng at
this point, it is a moving target and will move a lot in the next
months as well. But this is a topic for another thread, this one being
about the version number and this exact RFC.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
I am skeptical on bigint in the engine given what is possible now in
gmp. But yes, phpng is also a problem as it creates a total new code
base and barely blocks any other improvements. Why? Except that bigint
thing, I do not see many people trying to add stuff based on phpng at
this point, it is a moving target and will move a lot in the next
months as well. But this is a topic for another thread, this one being
about the version number and this exact RFC.
The problem is that people who want to add stuff for PHP 6 feel they have to add it to phpng, because if phpng is to be PHP 6, then it would need to be based off that branch.
--
Andrea Faulds
http://ajf.me/
I am skeptical on bigint in the engine given what is possible now in
gmp. But yes, phpng is also a problem as it creates a total new code
base and barely blocks any other improvements. Why? Except that bigint
thing, I do not see many people trying to add stuff based on phpng at
this point, it is a moving target and will move a lot in the next
months as well. But this is a topic for another thread, this one being
about the version number and this exact RFC.The problem is that people who want to add stuff for PHP 6 feel they have to add it to phpng, because if phpng is to be PHP 6, then it would need to be based off that branch.
Exactly, and for what I see, it is run forward and at some point we
will see a post asking to replace master with phpng and use it as base
for php6. To me this would be a bad thing, but this is the direction
phpng is taking.
--
Pierre
@pierrejoye | http://www.libgd.org
The problem is that people who want to add stuff for PHP 6 feel they have to add it to phpng, because if phpng is to be PHP 6, then it would need to be based off that branch.
I don't think it's a problem, because I don't think we're two years
away from releasing a phpng-based version and I don't think it's a
moving target at this point. So I agree we need to remove these
uncertainties.
I'm going to start an RFC-based discussion for moving phpng to master
so that the uncertainties around it are removed.
Zeev
I don't think it's a problem, because I don't think we're two years
away from releasing a phpng-based version and I don't think it's a
moving target at this point. So I agree we need to remove these
uncertainties.I'm going to start an RFC-based discussion for moving phpng to master
so that the uncertainties around it are removed.
phpng has mostly been just performance so far, right? Could we use this opportunity, where it is not yet master, to make some deeper improvements?
Andrea Faulds
http://ajf.me/
I don't think it's a problem, because I don't think we're two years
away from releasing a phpng-based version and I don't think it's a
moving target at this point. So I agree we need to remove these
uncertainties.I'm going to start an RFC-based discussion for moving phpng to master
so that the uncertainties around it are removed.phpng has mostly been just performance so far, right? Could we use this opportunity, where it is not yet master, to make some deeper improvements?
What do you mean by deeper improvements?
phpng is focused on performance. We can have other improvements for
the next version of PHP, of course...
Zeev
I don't think it's a problem, because I don't think we're two years
away from releasing a phpng-based version and I don't think it's a
moving target at this point. So I agree we need to remove these
uncertainties.I'm going to start an RFC-based discussion for moving phpng to master
so that the uncertainties around it are removed.phpng has mostly been just performance so far, right? Could we use this opportunity, where it is not yet master, to make some deeper improvements?
What do you mean by deeper improvements?
phpng is focused on performance. We can have other improvements for
the next version of PHP, of course…
Well, deep changes that break things are difficult to get into master normally.
Andrea Faulds
http://ajf.me/
I don't think it's a problem, because I don't think we're two years
away from releasing a phpng-based version and I don't think it's a
moving target at this point. So I agree we need to remove these
uncertainties.I'm going to start an RFC-based discussion for moving phpng to master
so that the uncertainties around it are removed.phpng has mostly been just performance so far, right? Could we use this opportunity, where it is not yet master, to make some deeper improvements?
What do you mean by deeper improvements?
phpng is focused on performance. We can have other improvements for
the next version of PHP, of course...
I'd like to start a discussion about IO multiplexing on that subject
as well. We could improve lots of performance of both the engine and
user scripts.
I already started a topic about it on internals, and I should write an
RFC about it.
I'm also worried about the API of future PHP-Next.
php-ng or not, I dont care. What I'd like is a clean API, and well
documented, so that it is not as hard to get into code as nowadays.
Nowadays its just very hard to put one's head into code when not
familiar with it. I want for PHP-Next something clean and documented
so that it will be even more open to new minds.
Julien.P
And here we go. So basically you are saying that once phpng is stabilized,
no matter the api/SRC cleanness, we are good for next. This is very bad and
I will vote -1 on anything close to this idea.
Besides that, the same kind of estimation was done for opcache, which was a
much smaller beast. They went bad by 300%, just saying.
The problem is that people who want to add stuff for PHP 6 feel they
have to add it to phpng, because if phpng is to be PHP 6, then it would
need to be based off that branch.I don't think it's a problem, because I don't think we're two years
away from releasing a phpng-based version and I don't think it's a
moving target at this point. So I agree we need to remove these
uncertainties.I'm going to start an RFC-based discussion for moving phpng to master
so that the uncertainties around it are removed.Zeev
The problem is that people who want to add stuff for PHP 6 feel they have to add it to phpng, because if phpng is to be PHP 6, then it would need to be based off that branch.
I don't think it's a problem, because I don't think we're two years
away from releasing a phpng-based version and I don't think it's a
moving target at this point.
Btw, It seems we follow a different branch. Alone today tells me that
it is still a moving target.
--
Pierre
@pierrejoye | http://www.libgd.org
This RFC attempts to settle the matter once and for all with a straight yes/no vote as to whether the name should be PHP 6. Should it pass, the matter is settled and we actually have a proper name for this fabled “PHP NEXT”. Should it fail, nothing is really lost, except that the discussion will inevitably resurface at some point. The plan, really, is to hopefully get it over with now so we don’t have to have this discussion later, avoiding potential future bikeshedding or derailment.
The RFC has been updated. I’ve backed down and made the vote be 50%+1 with the options PHP 6 and PHP 7. Hence only a plurality of votes is needed to win.
Hopefully this should be decisive, unless the number of Yes and No votes matches.
Andrea Faulds
http://ajf.me/
This RFC attempts to settle the matter once and for all with a straight yes/no vote as to whether the name should be PHP 6. Should it pass, the matter is settled and we actually have a proper name for this fabled “PHP NEXT”. Should it fail, nothing is really lost, except that the discussion will inevitably resurface at some point. The plan, really, is to hopefully get it over with now so we don’t have to have this discussion later, avoiding potential future bikeshedding or derailment.
The RFC has been updated. I’ve backed down and made the vote be 50%+1 with the options PHP 6 and PHP 7. Hence only a plurality of votes is needed to win.
I appreciate your change!
As such I'd like to coauthor it with you and represent the case for 7.
Zeev
I appreciate your change!
As such I'd like to coauthor it with you and represent the case for 7.
You’re welcome to edit the RFC and add a subsection with a case for 7. I’d appreciate it if you could discuss edits to the existing Rationale with me (I don’t want it to unintentionally be too 7-sided). If you can catch me on IRC, that would be optimal.
Andrea Faulds
http://ajf.me/
For my $0.02, as someone who put a fair amount of effort into PHP6 (function conversions, streams layer, etc...) I would really prefer to not call it PHP6. Whether not not it was ever released, it was a thing, and phpng (while awesome) is not that thing.
PHP7 seems the obvious choice, but I'm not that bothered if we call it something else. Just please not 6.
-Sara
As such I'd like to coauthor it with you and represent the case for 7.
Andrea, I would strongly recommend that you accept Zeev's offer and make
him a co-author. You did present at least a partial argument for breaking
the convention, but I think they do have a valid grievance in that some of
their arguments are being left-out. This is understandable, as you have a
bias in favor of preserving the order and keeping it at PHP 6. I actually
agree with you 100% on this-- but that just means that I'm biased, too.
It seems only fair that someone biased on the other side should be allowed
to present his arguments and I'm sure he can be trusted to keep his edits
to that one section. Likewise, you can then focus on expanding the
arguments for preserving the convention if you think that's necessary.
And thanks for updating the required majority. "2/3 either way" just
seemed too ambiguous and confusing. In the unlikely event of an exact tie,
I think we'd just regard the RFC as moot and proceed as if this RFC had
never been presented. I'll certainly be arguing strongly in favor of PHP 6
being the next version as I have in the past, but in the interest of
fairness, Zeev should be made a co-author and given the mandate to write a
section representing the arguments against PHP 6. That way, if the vote
goes for PHP 6 and people want to say it's because the arguments against in
the RFC weren't good enough, that'll be on him instead of you.
--Kris
Oh and a quick question: Could you clarify how many voting choices there
are going to be? The RFC only lists "PHP 6" and "PHP 7", yet it says that
a "plurality" will be required for a win, which means that there should be
at least 3 or more choices. A plurality basically means that you got the
most votes even if it's less than 50%, which can only happen if there aer 3
or more choices. Otherwise it's just a majority. Did you intend to list
another voting option? Or did you mean to say "simple majority" instead of
"plurality"?
Here's a quick rundown of the terms in question:
Super majority: Overwhelming support. Exact number varies. In the case
of PHP, it means 2/3 majority.
Simple majority: 50% + 1 vote.
Plurality: The most votes out of 3 or more choices, even if it's less than
50%. In many elections systems, in the event of a plurality, the top two
vote-getters will be chosen from in a run-off election to ensure that the
final choice has majority support.
--Kris
Oh and a quick question: Could you clarify how many voting choices there are going to be? The RFC only lists "PHP 6" and "PHP 7", yet it says that a "plurality" will be required for a win, which means that there should be at least 3 or more choices. A plurality basically means that you got the most votes even if it's less than 50%, which can only happen if there aer 3 or more choices. Otherwise it's just a majority. Did you intend to list another voting option? Or did you mean to say "simple majority" instead of "plurality"?
Here's a quick rundown of the terms in question:
Super majority: Overwhelming support. Exact number varies. In the case of PHP, it means 2/3 majority.
Simple majority: 50% + 1 vote.
Plurality: The most votes out of 3 or more choices, even if it's less than 50%. In many elections systems, in the event of a plurality, the top two vote-getters will be chosen from in a run-off election to ensure that the final choice has majority support.
Oops, my bad. The word “plurality” is indeed confusing in a two choice context. I’ve updated the section to clarify that there are only two votes, and used the phrase “simple majority”.
--
Andrea Faulds
http://ajf.me/
Andrea, I would strongly recommend that you accept Zeev's offer and make him a co-author. You did present at least a partial argument for breaking the convention, but I think they do have a valid grievance in that some of their arguments are being left-out. This is understandable, as you have a bias in favor of preserving the order and keeping it at PHP 6. I actually agree with you 100% on this-- but that just means that I'm biased, too.
It seems only fair that someone biased on the other side should be allowed to present his arguments and I'm sure he can be trusted to keep his edits to that one section. Likewise, you can then focus on expanding the arguments for preserving the convention if you think that's necessary.
Sure. I’ve already said I’m willing to accept contributions, not just from Zeev. Heck, it’s a wiki, anyone with karma could edit if they liked (but please ask first). All I’m waiting for is said contributions. :)
Andrea Faulds
http://ajf.me/