Hey ,
We've been talking about PHP6 for several weeks now.
From what I understand, we agreed on :
- We must release a new major version, ASAP I'd say
- It should be named "PHP6"
- It should break BC where needed, and introduce new concepts
- The main concept to concentrate on is Unicode implementation
- All ideas have been grouped at https://wiki.php.net/ideas/php6
- We go for a 2 year developpment iteration
All in one, 5.6 is going to be released in few months, and we now must
concentrate on PHP6.
For this, there are two needs :
- Start writing RFCs, PHP6 specific, and start debating ideas on an
"official" basis (RFCs + mail discussions) - Branch PHP6 , so that we can start hacking and get more motivations.
Thoughts about how/when to branch PHP6 ?
Julien Pauli
Hey ,
We've been talking about PHP6 for several weeks now.
From what I understand, we agreed on :
- We must release a new major version, ASAP I'd say
- It should be named "PHP6"
- It should break BC where needed, and introduce new concepts
- The main concept to concentrate on is Unicode implementation
- All ideas have been grouped at https://wiki.php.net/ideas/php6
- We go for a 2 year developpment iteration
All in one, 5.6 is going to be released in few months, and we now must
concentrate on PHP6.For this, there are two needs :
- Start writing RFCs, PHP6 specific, and start debating ideas on an
"official" basis (RFCs + mail discussions)- Branch PHP6 , so that we can start hacking and get more motivations.
Thoughts about how/when to branch PHP6 ?
Julien Pauli
I think we should use this opportunity to start following a more Git-style
branching model. Currently, every maintenance release increment exists as
its own separate branch; i.e. "PHP-5.5.10" is a branch and "PHP-5.5.11" is
a branch, and so on. This is redundant because we already have a tag for
each release. Additionally, it also forces us to target features for one
or more specific maintenance version increments. A more flexible approach
would be to have each increment reflect the totality of what's been merged
in as stable as of whenever the increment went to release.
This can get complicated and confusing so I'll do my best to articulate
exactly what it is I'm proposing and why. It's very similar in principle
to how the Gitflow model works..
Under the current model (as best as I can decipher from gitk, at least),
the PHP-5.4 branch merges into master and PHP-5.5. PHP-5.5 then merges
into PHP-5.6. PHP-5.6 (the most recent increment) then merges into master.
Each of these minor versions are then branched off into a maintenance
version branch every time a maintenance release occurs. These branches
eventually just remain dead, at least some without being merged back into
anything. It's already a confusing mess and it's only going to get worse
at this rate. Just type "gitk --all" sometime and see how much of it you
can make sense of without getting a migraine.
What I'm suggesting is a cleaner, more logical approach that doesn't force
us to keep a dead branch for every maintenance release. Let's start with
creating the PHP-6 branch....
- Create branch PHP-6 based off of master (master->PHP-6).
- Commits related to work on PHP 6. See explanation about feature
branching below. - When we decide we have enough for a minor release, create a new
branch based off of PHP-6 (PHP-6->Release-PHP-6.0).- This is the cuf-off point for noteworthy new features and whatnot.
- Commits on this branch will pertain mostly to bug fixes and maybe
trivial feature changes/etc. - Work on everything else will continue in parallel on PHP-6.
- Release-PHP-6.0 will occasionally be merged into PHP-6
(PHP-6<-Release-PHP-6.0). However, commits to PHP-6 will NOT be merged
into the minor release branch. - If we have a bug fix that we want to incorporate into an
older-yet-supported version, make the change on one of the
Release branches
then merge it into the other-- if that can be done without
creating a merge
conflict. Otherwise, we'd want to manually commit it to the
others. Just
depends on how different the surrounding code is between the minor
increments.
- When the Release-PHP-6.0 branch is deemed ready for a release
(commits to that point could be treated as release candidates):- Tag the commit with the maintenance release version. The first one
would be "PHP-6.0.0". - This would be a good time to merge it into PHP-6, as well.
- Tag the commit with the maintenance release version. The first one
- Repeat Step 4 for the duration of the 6.0 lifecycle. Each subsequent
commit tag will increment "PHP-6.0.1", "PHP-6.0.2", and so on. Again:
Commits to PHP-6 will NOT be merged here; however, commits here will be
merged back into PHP-6. - When the PHP-6 branch is ready for a new minor version increment,
repeat Steps 3 - 5, except increment it to "Release-PHP-6.1" and so-on. - When a minor release's lifecycle is over and we're no longer
supporting it (i.e. there will be no more maintenance releases), merge the
release branch into PHP-6 (i.e. PHP-6<-Release-PHP-6.0) and delete the
release branch. So long as you use the "--no-ff" switch when merging, the
complete history for that former branch will be preserved and the chart
will look MUCH nicer!
This model would allow us to have a much more organized and easy to follow
commit history. Every single version increment will still be accessible
via tags just as they are now and the temporary Release branches will
appear in the history even after they're gone.
One of the advantages to this approach is that people will no longer have
to decide which minor increment(s) to target something for, nor will they
have to worry about having to merge it into a ton of different places. It
will also make it a LOT easier to enforce a cut-off for new features/etc
into a minor release. It'll force us to limit maintenance releases to,
well, maintenance. Meanwhile, if something isn't there in time for 6.2,
it'll just go into 6.3 instead if it's ready by then. A developer would
then simply have to decide whether something should be targetted for the
next minor release (i.e. commit to PHP-6) or whether it's within the scope
of a maintenance release (i.e. commit to one or more of Release-PHP-6.x
then merge back into PHP-6).
On a separate note, as alluded to in Step 2, I'd also recommend using
feature branches instead of committing directly into the "trunk" for a
given version. For example, I create a LOCAL branch called "Bug_53333" off
of "Release-PHP-6.0". I make several commits while working on fixing this
bug over the course of several days. When it's done, just like with the
Release branches, I merge the feature branch back into Release-PHP-6.0
(using "--no-ff" to preserve the commit history and feature branch name at
the merge point) and delete the feature branch. Note that the feature
branch is never pushed to the host repo; it exists solely on the dev's
local machine. However, when the dev pushes Release-PHP-6.0, the commits
and the branch name will appear in the history, which will make it a lot
easier to read. Furthermore, this has the advantage of making sure all the
commits related to the fix are pushed at once so the release manager
doesn't have to worry about a partial bug fix sitting there potentially
breaking the release, forcing them to either rewind or wait for the other
commits to arrive.
I didn't include the feature branch part in the numbered list because I
wanted to communicate the basic structure as clearly as possible.
Furthermore, it'll still work without using local feature branches, though
using them solves a lot of problems and makes the history more
human-friendly.
I realize this may look complicated-- particularly to people more
accustomed to Subversion-style branching-- but the benefits far exceed any
learning curve involved. Furthermore, we could start doing this with PHP
6; it wouldn't have any effect on how we're doing the branching for PHP 5.
If we go with that model, we could get started on the new PHP-6 branch
right away or whenever we all decide it's time to get it underway.
Thoughts? If it'll help, I can create a mock repo to demonstrate this
approach and how much easier it is to review and work with.
--Kris
I think we should use this opportunity to start following a more Git-style
branching model. Currently, every maintenance release increment exists as
its own separate branch; i.e. "PHP-5.5.10" is a branch and "PHP-5.5.11" is
a branch, and so on. This is redundant because we already have a tag for
each release. Additionally, it also forces us to target features for one
or more specific maintenance version increments. A more flexible approach
would be to have each increment reflect the totality of what's been merged
in as stable as of whenever the increment went to release.
These release branches are owned by the RM. No other developers should
touch them. The only commits there should be related to release process
or critical cherry picked fixes.
The decision the developer has to make is whether a change should make
5.4, 5.5, 5.6 or newer, not the actual release. New features should only
be merged in the top most branch.
On the dead release branches see my message from yesterday:
http://news.php.net/php.internals/73514
On a separate note, as alluded to in Step 2, I'd also recommend using
feature branches instead of committing directly into the "trunk" for a
given version. For example, I create a LOCAL branch called "Bug_53333" off
of "Release-PHP-6.0". I make several commits while working on fixing this
bug over the course of several days. When it's done, just like with the
Release branches, I merge the feature branch back into Release-PHP-6.0
(using "--no-ff" to preserve the commit history and feature branch name at
the merge point) and delete the feature branch.
This already happens for many larger changes. Most changes are small and
a single commit or are rewritten into one, though.
johannes
On Thu, Apr 3, 2014 at 4:19 AM, Johannes Schlüter johannes@schlueters.dewrote:
I think we should use this opportunity to start following a more
Git-style
branching model. Currently, every maintenance release increment exists
as
its own separate branch; i.e. "PHP-5.5.10" is a branch and "PHP-5.5.11"
is
a branch, and so on. This is redundant because we already have a tag for
each release. Additionally, it also forces us to target features for one
or more specific maintenance version increments. A more flexible
approach
would be to have each increment reflect the totality of what's been
merged
in as stable as of whenever the increment went to release.These release branches are owned by the RM. No other developers should
touch them. The only commits there should be related to release process
or critical cherry picked fixes.
The decision the developer has to make is whether a change should make
5.4, 5.5, 5.6 or newer, not the actual release. New features should only
be merged in the top most branch.
By release branch, are you referring to minor releases or maintenance
releases? If the latter, it'd be a moot point under this model because
we'd be getting rid of separate branches for maintenance releases
altogether. Instead, the RM would simply apply the tag to the commit where
they want the maintenance release to occur. That would be a much cleaner
approach than what we're doing now.
If you want to continue having a gatekeeper approach with only one person
having access to a minor increment branch, a simple alternative would be to
have people push their feature branches if they believe the commits should
go on one or more minor increments. Then, the release manager for each
minor increment (i.e. there'd be an RM for 6.0 and 6.1 instead of for each
individual maintenance increment) would decide whether or not to merge that
feature branch in. The feature branch itself would be based on a minor
release branch and subsequently deleted after it's either merged or
rejected.
--Kris
On Thu, Apr 3, 2014 at 4:19 AM, Johannes Schlüter johannes@schlueters.dewrote:
I think we should use this opportunity to start following a more
Git-style
branching model. Currently, every maintenance release increment exists
as
its own separate branch; i.e. "PHP-5.5.10" is a branch and "PHP-5.5.11"
is
a branch, and so on. This is redundant because we already have a tag
for
each release. Additionally, it also forces us to target features for
one
or more specific maintenance version increments. A more flexible
approach
would be to have each increment reflect the totality of what's been
merged
in as stable as of whenever the increment went to release.These release branches are owned by the RM. No other developers should
touch them. The only commits there should be related to release process
or critical cherry picked fixes.
The decision the developer has to make is whether a change should make
5.4, 5.5, 5.6 or newer, not the actual release. New features should only
be merged in the top most branch.By release branch, are you referring to minor releases or maintenance
releases? If the latter, it'd be a moot point under this model because
we'd be getting rid of separate branches for maintenance releases
altogether. Instead, the RM would simply apply the tag to the commit where
they want the maintenance release to occur. That would be a much cleaner
approach than what we're doing now.If you want to continue having a gatekeeper approach with only one person
having access to a minor increment branch, a simple alternative would be to
have people push their feature branches if they believe the commits should
go on one or more minor increments. Then, the release manager for each
minor increment (i.e. there'd be an RM for 6.0 and 6.1 instead of for each
individual maintenance increment) would decide whether or not to merge that
feature branch in. The feature branch itself would be based on a minor
release branch and subsequently deleted after it's either merged or
rejected.--Kris
So, for example, if I'm committing a new feature or whatever, I'd just
merge it into PHP-6 as described in my previous email. If, however, it's a
bug fix or something else I think should go in a current minor branch, I'd
push the feature branch with the commits and leave it to the various RMs to
decide whether or not to merge it in. RM for Release-PHP-6.0 may decide
it's not needed but the RM for Release-PHP-6.1 decides to merge it in.
That person would then tag the next maintenance release increment as
described earlier, except in this scenario they would be the only person
with the ability to commit/merge to that branch. This way, RMs continue
having control over release branches, just as they do now, while having a
vastly improved branching model.
--Kris
By release branch, are you referring to minor releases or maintenance
releases? If the latter, it'd be a moot point under this model because
we'd be getting rid of separate branches for maintenance releases
altogether. Instead, the RM would simply apply the tag to the commit where
they want the maintenance release to occur. That would be a much cleaner
approach than what we're doing now.
The past shows that in practice this won't work. We had enough incidents
in the past where "small" changes after an RC roe the release. That's
why we created the strict rule of using those release branches.
If you want to continue having a gatekeeper approach with only one person
having access to a minor increment branch, a simple alternative would be to
have people push their feature branches if they believe the commits should
go on one or more minor increments. Then, the release manager for each
minor increment (i.e. there'd be an RM for 6.0 and 6.1 instead of for each
individual maintenance increment) would decide whether or not to merge that
feature branch in. The feature branch itself would be based on a minor
release branch and subsequently deleted after it's either merged or
rejected.
Neither do we have the resources for constant gatekeeping nor is that
the spirit. In general we trust developers to do the right things and
prefer fixing mistakes afterwards over preventing improvements by
process.
The reason why we have the "ugly" history comes more from the fact that
we have long living feature branches branched of quite some time ago
(i.e. pull requests) which then are merged in, instead of e.e. rebaseing
the first.
johannes
On Thu, Apr 3, 2014 at 5:20 AM, Johannes Schlüter johannes@schlueters.dewrote:
By release branch, are you referring to minor releases or maintenance
releases? If the latter, it'd be a moot point under this model because
we'd be getting rid of separate branches for maintenance releases
altogether. Instead, the RM would simply apply the tag to the commit
where
they want the maintenance release to occur. That would be a much cleaner
approach than what we're doing now.The past shows that in practice this won't work. We had enough incidents
in the past where "small" changes after an RC roe the release. That's
why we created the strict rule of using those release branches.
That wouldn't happen if the RM controlled commits to the minor release
branch.
If you want to continue having a gatekeeper approach with only one person
having access to a minor increment branch, a simple alternative would be
to
have people push their feature branches if they believe the commits
should
go on one or more minor increments. Then, the release manager for each
minor increment (i.e. there'd be an RM for 6.0 and 6.1 instead of for
each
individual maintenance increment) would decide whether or not to merge
that
feature branch in. The feature branch itself would be based on a minor
release branch and subsequently deleted after it's either merged or
rejected.Neither do we have the resources for constant gatekeeping nor is that
the spirit. In general we trust developers to do the right things and
prefer fixing mistakes afterwards over preventing improvements by
process.
Actually, that's extremely easy to accomplish with Git. Gitolite, for
example, enables the use of branch-specific permissions for different users.
Besides, my point was that this branching model can easily accommodate both
scenarios with and without a gatekeeper.
The reason why we have the "ugly" history comes more from the fact that
we have long living feature branches branched of quite some time ago
(i.e. pull requests) which then are merged in, instead of e.e. rebaseing
the first.
That's part of it, but I've also noticed a ton of criss-crossed merging
happening between version branches. That, more than anything I think,
makes it a nightmare to read. Furthermore, there's simply no need to have
an ever-increasing number of dead branches that lead nowhere and never
merge back. If somebody wants to find a specific version, that's what tags
are for.
--Kris
Hi!
That's part of it, but I've also noticed a ton of criss-crossed merging
happening between version branches. That, more than anything I think,
What criss-crossed merging? Newer branches should never be merged into
older ones, so I don't see how any criss-crossing is possible.
makes it a nightmare to read. Furthermore, there's simply no need to have
an ever-increasing number of dead branches that lead nowhere and never
merge back. If somebody wants to find a specific version, that's what tags
Branches are dirt-cheap in git, so dead branches is not a problem. Also,
the only dead branches are supposed to be release branches and very
rarely feature branches, all the rest should be done in private branches
and submitted as pull request.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
makes it a nightmare to read. Furthermore, there's simply no need to have
an ever-increasing number of dead branches that lead nowhere and never
merge back. If somebody wants to find a specific version, that's what tagsBranches are dirt-cheap in git, so dead branches is not a problem. Also,
the only dead branches are supposed to be release branches and very
rarely feature branches, all the rest should be done in private branches
and submitted as pull request.
The usual git workflow which I’ve seen in the wild is:
- release branch is created
- release-specific commits are added
- tag (optionally signed) is created
- branch is removed
In case development has to be restarted (for hotfix-patch), new branch is created from the tag-point.
The advantage is, that “branches” represent points of active development and tags represent history.
Advantage is purely semantical, of course
--
Alexey Zakhlestin
CTO at Grids.by/you
https://github.com/indeyets
PGP key: http://indeyets.ru/alexey.zakhlestin.pgp.asc
On Sat, Apr 5, 2014 at 12:19 AM, Alexey Zakhlestin indeyets@gmail.comwrote:
makes it a nightmare to read. Furthermore, there's simply no need to
havean ever-increasing number of dead branches that lead nowhere and never
merge back. If somebody wants to find a specific version, that's what
tagsBranches are dirt-cheap in git, so dead branches is not a problem.
I disagree. When you have far more dead branches than active ones, with
the gap only widening as time goes forward, it becomes increasingly
difficult to quickly locate active branches of development. There's simply
no reason to leave dead branches out there when quick access to past
versions can be achieved through tags, which we're already doing anyway.
Also,
the only dead branches are supposed to be release branches and very
rarely feature branches, all the rest should be done in private branches
and submitted as pull request.
In ideal Git workflow, release branches should never lie dead like this.
Instead, they are merged back into the trunk branches-- no fast forward to
preserve history-- and deleted. Tags are used to enable users to quickly
go back to key points in history; i.e. version releases.
Regarding RM control, the workflow I've suggested would not disrupt that at
all. The RM would still have full control over what goes onto the release
branch and when, as well as where and when tags are applied. But in this
scenario, once the lifecycle of that release is over, the release branch is
merged back in one last time and deleted. The history is preserved but it
doesn't leave a dead branch.
If we had been using this approach to-date, we'd have just a few branches
instead of, well, dozens, most of which are defunct and no longer serve any
purpose except to clutter.
The usual git workflow which I've seen in the wild is:
- release branch is created
- release-specific commits are added
- tag (optionally signed) is created
- branch is removed
In case development has to be restarted (for hotfix-patch), new branch is
created from the tag-point.The advantage is, that "branches" represent points of active development
and tags represent history.
That's essentially correct. What we're doing right now is having more and
more branches created to represent points of development that are no longer
active. That is, in fact, exactly what tags are for in Git.
--Kris
Hi!
the gap only widening as time goes forward, it becomes increasingly
difficult to quickly locate active branches of development. There's
Here's the algorithm: active ones are named "master" or have one dot in
them. How hard is that? That putting aside the fact that there's not so
many of them that a person smart enough to write code that should be
committed to PHP repository wouldn't be able to just remember them.
In short, I'm not sure I see what advantage spending time on removing
the branches give us. Their cost is zero, while our time costs more than
zero.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Sat, Apr 5, 2014 at 10:32 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
the gap only widening as time goes forward, it becomes increasingly
difficult to quickly locate active branches of development. There'sHere's the algorithm: active ones are named "master" or have one dot in
them. How hard is that? That putting aside the fact that there's not so
many of them that a person smart enough to write code that should be
committed to PHP repository wouldn't be able to just remember them.In short, I'm not sure I see what advantage spending time on removing
the branches give us. Their cost is zero, while our time costs more than
zero.
There are more active branches than that. For example the two str_size_*
branches. Sometimes people also commit other work in progress branches. A
github fork of a semi-active PHP core developer likely has at least ten
additional "active" (as in, not yet merged) branches.
I think keeping around dead branches does have a cost. It blows up branch
listings significantly. If you open the branch list on github and try to
find something you'll end up scrolling through more than fifty release
branches and other dead ends.
Nikita
Hi!
A github fork of a semi-active PHP core developer likely has at least
ten additional "active" (as in, not yet merged) branches.
These branches are in dev's private fork, so I'm pretty confident the
devs can manage their own backyard. They also don't have to import every
branch from main repo to their private repo, AFAIK.
I think keeping around dead branches does have a cost. It blows up
branch listings significantly. If you open the branch list on github and
try to find something you'll end up scrolling through more than fifty
release branches and other dead ends.
It has a completion widget there, and I still not sure what is
"something" you're looking for there. Is it "PHP-5.6"? It's not hard to
find then, you know its name. The issue seems to me getting much more
attention than it deserves.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
On Sat, Apr 5, 2014 at 11:43 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
A github fork of a semi-active PHP core developer likely has at least
ten additional "active" (as in, not yet merged) branches.These branches are in dev's private fork, so I'm pretty confident the
devs can manage their own backyard. They also don't have to import every
branch from main repo to their private repo, AFAIK.I think keeping around dead branches does have a cost. It blows up
branch listings significantly. If you open the branch list on github and
try to find something you'll end up scrolling through more than fifty
release branches and other dead ends.It has a completion widget there, and I still not sure what is
"something" you're looking for there. Is it "PHP-5.6"? It's not hard to
find then, you know its name. The issue seems to me getting much more
attention than it deserves.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227--
You are correct in that it's not a catastrophic issue or anything. But
even if it's not that big a deal, it's still a mess. And I guess the point
I'm making is that, if there's a cleaner way of doing this that doesn't
introduce any costs or other drawbacks (which there is and it doesn't),
then why not do it the cleaner way going forward starting with PHP 6?
Here's a quick breakdown of what we'd be looking at:
- Release managers would continue to have exclusive commit access to
release branches. - Current and past versions would still be quickly and easily accessible
via tags, just as they are now. - Branching would better reflect segregation of maintenance releases
from trunk commits. - Feature branching would be consistent and would not add to clutter.
- The corpses of old EOL branches would no longer pile-up and linger for
eternity. - The reduced clutter will make it easier to locate active branches and
much easier to read and make sense of the commit history.
On the flip side, there really aren't any drawbacks. The only case against
doing this that I'm seeing is "it's no big deal". Maybe it's not that big
a deal, but it's still an improvement that doesn't introduce any adverse
consequences. I realize that some people who are still Git-weary might be
a little reluctant to tweak the branching procedure at all, but it's really
not as complicated as it sounds.
--Kris
Hi!
By release branch, are you referring to minor releases or maintenance
releases? If the latter, it'd be a moot point under this model because
we'd be getting rid of separate branches for maintenance releases
altogether. Instead, the RM would simply apply the tag to the commit where
they want the maintenance release to occur. That would be a much cleaner
approach than what we're doing now.
It is not. Especially not when we have many people that can commit code
in any moment. RM should be able to create a stable release branch and
do all the release work in this branch knowing it is not going to
change, it can be verified, and it can be amended with urgent fixes (or,
sometimes, removing certain changes) without having to pull in all the
delta of unverified code that happened in between. Tags are not meant
for that, release branches are meant exactly for that. I see absolutely
no reason why what we are doing now is in any way "unclean".
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hey ,
We've been talking about PHP6 for several weeks now.
From what I understand, we agreed on :
- We must release a new major version, ASAP I'd say
- It should be named "PHP6"
- It should break BC where needed, and introduce new concepts
- The main concept to concentrate on is Unicode implementation
- All ideas have been grouped at https://wiki.php.net/ideas/php6
- We go for a 2 year developpment iteration
All in one, 5.6 is going to be released in few months, and we now must
concentrate on PHP6.For this, there are two needs :
- Start writing RFCs, PHP6 specific, and start debating ideas on an
"official" basis (RFCs + mail discussions)- Branch PHP6 , so that we can start hacking and get more motivations.
Thoughts about how/when to branch PHP6 ?
I would suggest not creating a separate branch and instead declare that
master is to become PHP6 - branch only once we get close to doing
releases / feature freeze. (Basically, how it we already do it for the
minor versions, the initial development happens on master). This would
avoid having to merge yet another branch (four active branches is quite
enough, I think).
If we decide to also have a PHP 5.7 release (which, according to various
OTR discussions, isn't particularly certain), we can branch that off
PHP-5.6 lateron. From what I understood, if we want to do a 5.7 release it
will be light on feature additions and be mainly concerned with paving the
group for PHP 6 (deprecations, compatibility, etc).
And also, I would strongly suggest to drop the focus on unicode - or any
other feature in particular. We need a new major version, regardless of
whether it offers magical unicode support (or only non-magical unicode
support). Absence of significant progress in that direction should not be a
show-stopper for a PHP6 release.
Thanks,
Nikita