Hold off 5.4

and we didn't even discussed the current implementations, because the
discussion was halted until the new revised patch is complete.
which seems will be rolled out without further discussion.

Really? You had all the opportunity to comment on either my
announcement:
http://thread.gmane.org/gmane.comp.php.devel/62298/focus=62510
to which Dmitry and Stas commented; as well as my mail:
http://thread.gmane.org/gmane.comp.php.devel/62298/focus=62858
that annouced the third compromise implementation.

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

Are we effectively going to create the original type checking
implementation, but in a separate component people would have to
install - thereby creating two very different flavors of PHP?

It's clearly a debugging aid for me. So this should be in a debugging
extension. I doubt any sort of shared hoster would install it, but it
does give people the power to do this for their own controlled set-up.
Also, if the extension is suddenly not there, the app will still work so
I am not buying your "two flavours" argument.

While the code may still work, it won't work as expected. If the
PHP interpreter can execute the application, then it should provide the
same output given the same input -- and this would not be the case.
That's the two flavours argument.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

For the record, I'm still very uncomfortable with this new language
syntax - even if it's a no-op right now.

I know you are; but from what I understood, there were no more comments
to the latest mail (with patch and RFC) that I've made towards this.

I know, I took some time off after reaching agreement we're not going to add strict checks - but I said from the get go that it's questionable whether we should add this syntax.

I'm not comfortable about not having the proper strict checks that we had.

Except we never had them. It's like me committing support for inline assembly syntax or whatever other weird idea I might come up with, and then saying I don't feel comfortable about removing it. With such fundamental changes there should be a very broad support, with the status-quo being the default in case no such broad support is reached. The status quo is not the latest state of trunk, but rather, the state of previous versions.

It seems we're both having to live with something uncomfortable.

We should attribute as much importance to adding features as removing features; Can I jump ahead and remove this support in trunk, and get back to you with 'one of us will have to feel uncomfortable' feedback? I don't think it works that way. The status quo, and the way PHP existed since forever, is no strict type checking or syntax for supporting it. IMHO before there's a clear informed decision to change that, it should stay that way.

With the kind of phpdoc updates we're likely to add, you should be able to implement your extension-level support on top of this meta data. The chances of that becoming mainstream and creating two flavors of PHP are much slimmer which make it a much better fit than a big chunk of language level syntax that's a no-op by default.

Are we effectively going to create the original type checking
implementation, but in a separate component people would have to
install - thereby creating two very different flavors of PHP?

It's clearly a debugging aid for me. So this should be in a debugging
extension. I doubt any sort of shared hoster would install it, but it
does give people the power to do this for their own controlled set-up.
Also, if the extension is suddenly not there, the app will still work so I am not
buying your "two flavours" argument.

It may or may not work depending on how you write your code. If you rely on that feature your app may very well stop working properly (e.g. it may expose it to security issues).
It's very much creating two flavors.

Regarding the alpha release, I think there are two key issues here:

1. Does this alpha mean anything at all. Some, myself included,
   don't feel comfortable about the state of certain things in the
   current codebase (example given above). Are we all in sync that even
   if a certain feature makes it into the alpha, it doesn't mean that it
   won't be removed or be severely modified in an upcoming beta/GA?
   Is it clear it has no implications on when the final release would be?
   That is, at least, the way I perceive alpha releases. In which case
   it's not exactly clear to me what the benefits of releasing an Alpha
   in this day and age for PHP - where we have snapshots every few hours.
   We need to have a very clear understanding of what this does or
   doesn't mean, and make sure we communicate it properly to the users.

To me this alpha would be a "this is what we're mostly likely going to have
thing". I wouldn't like to see new major features, engine rework being done;
but I also think we shouldn't try to remove stuff from it unless really
necessary.

If that's the case, count me in those who oppose the release of the current codebase as an alpha.

Zeev

Hi!

During our namespace discussion, this is exactly what I warned about. In
order to make use of namespaces, you need to have atleast two "elements"
in your class names otherwise we can still never introduce a new class.
But that was not listened too.

I'm not sure I understand this point, could you explain?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

. classes named as any of the type hint scalar types
do not work anymore
aka class int {}

Yeah, there is a slight hint of a BC break in case you have a class
named "int" or "float" etc. But there is:
http://uk.php.net/manual/en/userlandnaming.tips.php

Perhaps we can reduce the current list of classes:
int, integer, real, double, string, binary, scalar, array, object,
bool, boolean
to what the manual uses though (for prototypes):
int, float, string, binary, scalar, array, object, bool
(Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php)

Sorry, but this is actually a pretty grave BC break.

Currently, you can do the following:

namespace Foo\Validator;

class Int {}

During our namespace discussion, this is exactly what I warned about. In
order to make use of namespaces, you need to have atleast two "elements"
in your class names otherwise we can still never introduce a new class.
But that was not listened too.

As Sebastian noted, it seems this should be addressed with the new
lexer; I'd argue that if the current type hinting must introduce new
keywords, it should wait until the new lexer is in place in order to
insulate end-users from such changes.

The new lexer however, is a slower; so not a viable solution right now.

With a defined release process, everyone knows what must be done, by
when, making the process more transparent and gasp democratic.

Well, I don't think we've ever been democratic. I probably think
that that wouldn't even work. Also, I think an alpha has pretty much
been announce nicely on time for people to know what's happening.

I think what Matthew suggest here is something in the line of democratically
defining a release process up front: features you would like to get in (a
roadmap that clearly states that the content can change up until a feature
freeze), a deadline for the feature freeze so that the process is
predictable and appoint a release manager to be in charge of the branch.

Something like:

• Branching next version from day one so you have one called next and one
  called trunk for edge stuff, and appoint a release manager to approve
  features as they are merged from development branch(es)
  Alternatively (among several possible branch strategies) in DVCS you could
  use topic branches for the edge implementations, this is cleaner (maybe),
  but the point is to have a release branch that can be stabilized at anytime.
  For a more in-depth branching possibility see:
  http://nvie.com/posts/a-successful-git-branching-model/

• Define a feature freeze date, anything not ready feature or stability wise
  is moved to Next Next roadmap (they are not in the Next release branch
  anyway as it only has feature complete features at any point)
  And branch off Next Next and appoint a release manager for that branch so
  there is always an active release branch.

This will give a more predictable release schedule for everyone involved,
especially for php users as it will give them a real hint on when the
testing process of the next version will begin and some clue on when it
might get finalized. All without having to introduce full fledge scrum and /
or a strict release process.

• ar

hi,

Well, I don't think we've ever been democratic.

Neither have we been dictatorial. Announcing a new major (x.y+1.z)
release in the middle of some of the largest conferences (knowing that
many core devs won't follow the list) and for a couple of weeks later
was not the best thing to do. To commit something that did not get any
consensus and then force us to go out with a release is bad.

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

2010/11/25 Davey Shafik davey@php.net:

5.4 should be hold off until we solved the listed issues and the
release management RFC gets discussed and hopefully approved.

The reality is that trunk is not going to be 5.4; it cannot be in its current state.

The reason behind ditching the unicode php6 was to enable innovation in trunk. This meant
we could have traits, type hinting, apc in core etc, as well as internal enhancements, the new lemon
parser etc. Regardless of the arguments and unresolved issues, this IS happening, and IS a good thing.

The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk
and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks.

This is an unreliable, laborious, crappy method for creating stable branches, and managing the
repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so creating feature branches and
re-integrating is also a pretty crappy solution.

So, with the BC breaks committed to trunk (register globals) or that we want to commit to trunk (magic quotes), as
well as the code without consensus, creating a stable 5.4 branch is going to be a lot of work.

Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main repo, but have several small projects on
github), but it seems that it's capabilities would make these things much more trivial. Obviously: not a solution for now.

We need to get our repo in order first, then we can start talking about 5.4. The RMs need to make a definitive
stand about how the repo will be managed, and explain to us how that's going to trickle down to our personal habits.

This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should  maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks).

Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. This gives people buildable
(hopefully) branches to use for testing, revision control for those developing the features, and unmuddied commit histories
to more easily pull those changes into the appropriate branches.

• Davey
  --

I think Davey has a clear view and a good explanation about the
current situation.
Trunk has been used for both short and long term development hence the
difficulties to agree that trunk is about 5.4 or +.

In a first place, we should decide on what to have for 5.4 and what to
leave for the future.

A technical way to do it would be to use git-svn locally, starting
from the PHP_5_3 branch and merging it with trunk. git rebase -i can
then be used easily to remove all the commits we don't want to appear
in 5.4.

--
Patrick

Who says it has to be 5.4? People seem to be a bit fixated on the version there.
Major BC breaks just means the version released from trunk is 6.0. And it's just a number. Big number, but still just a number.

Merging (by and or by magic :) features into branch created from 5.3 just sounds like plane crash waiting to happen..

---Jani

5.4 should be hold off until we solved the listed issues and the
release management RFC gets discussed and hopefully approved.

The reality is that trunk is not going to be 5.4; it cannot be in its current state.

The reason behind ditching the unicode php6 was to enable innovation in trunk. This meant
we could have traits, type hinting, apc in core etc, as well as internal enhancements, the new lemon
parser etc. Regardless of the arguments and unresolved issues, this IS happening, and IS a good thing.

The goal then was to essentially take the 5.3 branch, create a 5.4 branch, cherry pick commits to trunk
and apply them to the 5.4 branch and end up with a stable build. Unfortunately, subversion merging sucks.

This is an unreliable, laborious, crappy method for creating stable branches, and managing the
repo. Worse yet, SVN's merge-tracking/branch reintegration also sucks, so creating feature branches and
re-integrating is also a pretty crappy solution.

So, with the BC breaks committed to trunk (register globals) or that we want to commit to trunk (magic quotes), as
well as the code without consensus, creating a stable 5.4 branch is going to be a lot of work.

Now, I'm no advocate of git (I've yet to jump on the bandwagon for my main repo, but have several small projects on
github), but it seems that it's capabilities would make these things much more trivial. Obviously: not a solution for now.

We need to get our repo in order first, then we can start talking about 5.4. The RMs need to make a definitive
stand about how the repo will be managed, and explain to us how that's going to trickle down to our personal habits.

This doesn't seem the ideal time to introduce a new toolchain, so sticking with SVN, we should maintain 4 branches, 5.2 (security only), 5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC breaks), 6.0 (BC breaks).

Non-agreed upon enhancements, potential BC breaks, all should be done in feature branches. This gives people buildable
(hopefully) branches to use for testing, revision control for those developing the features, and unmuddied commit histories
to more easily pull those changes into the appropriate branches.

• Davey

The goal then was to essentially take the 5.3 branch, create a 5.4
branch, cherry pick commits to trunk and apply them to the 5.4 branch
and end up with a stable build. Unfortunately, subversion merging
sucks.

This has nothing to do with any sort of version control sucking. Cherry
picking is hard! It only works if you get one feature in one commit,
instead of many several, with other changes in between, without many
dependices between patches. PHP isn't like that, especially with
Dmitry's engine changing patches.

This doesn't seem the ideal time to introduce a new toolchain, so
sticking with SVN, we should maintain 4 branches, 5.2 (security only),
5.3 (bug fixes + security), 5.4 (agreed upon enhancements, no BC
breaks), 6.0 (BC breaks).

Four branches? Are you going to help?

Non-agreed upon enhancements, potential BC breaks, all should be done
in feature branches.

That's a good theoretical point of view. And I maintain it doesn't work.
It makes it for example very difficult to try out multiple new features
at the same time; to say, to try to figure our whethr your app will
still works. It's also a lot more egocentric thing, instead of
collaboration. You want your stuff exposed to as many developers as
possible (that's also why I am not a fan of DVCS, because it reduces
that exposure drastically).

Derick