Fixing config normalisation example in docblock
merged branch richardmiller/fixing_config_docblock (PR #5542)

Commits
-------

1402b42 Fixing config normalisation example in docblock

Discussion
----------

Fixing config normalisation example in docblock

Against 2.0 this time

as per @stof's comments in symfony/symfony-docs#1721

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: -
Fixes the following tickets: -
Todo: -
License of the code: MIT
composer is available in travis workers
updated CHANGELOG for 2.1.2
updated VERSION for 2.1.2
bumped Symfony version to 2.1.3-DEV
merged branch krmcbride/flash-phpdoc (PR #5557)

Commits
-------

bb0e4c3 Fixed FlashBagInterface phpdoc, clarified UPGRADE docs

Discussion
----------

Fixed FlashBagInterface phpdoc, clarified upgrade doc

The fact that multiple flash messages are now stored/retrieved per type was an additional BC break that I missed when I first went through the 2.1 update doc, and it didn't help that the phpdoc was outdated.

These changes just clarify things a little.

---------------------------------------------------------------------------

by drak at 2012-09-20T07:45:52Z

+1
merged branch bamarni/patch-6 (PR #5548)

Commits
-------

589a8b3 composer is available in travis workers

Discussion
----------

composer is available in travis workers

---------------------------------------------------------------------------

by bamarni at 2012-09-19T09:07:30Z

reverted

---------------------------------------------------------------------------

by stof at 2012-09-19T09:59:21Z

btw, in the 2.1 branch, the ``COMPOSER_ROOT_VERSION`` varaible should be set to ``2.1.x-dev``

---------------------------------------------------------------------------

by bamarni at 2012-09-19T14:44:48Z

@stof: ok, btw I don't understand the issue, deps are solvable without this, is it a workaround to make this package known as 2.1 even though it's not guessable with the branch name (eg. when using a feature branch for a PR)? I thought this was handled by the branch-alias.

---------------------------------------------------------------------------

by stof at 2012-09-19T15:54:05Z

@bamarni It is solvable in some cases but not in all of them. Sometimes, when being in a detached head (which is the case when Travis builds PRs), the guessing of the composer root version does not work, and so symfony dev deps depending on some symfony components (Doctrine) will fail because the guessed version would not match ``2.*`` (which is the Doctrine requirement for the components).

branch aliases have nothing to do with the guessing of the version for the root package.

---------------------------------------------------------------------------

by stof at 2012-09-19T15:55:25Z

btw, the only cases where COMPOSER_ROOT_VERSION could be needed is when some of your dependencies have a requirement on your root package. Otherwise, the root version is never needed by composer to resolve deps

---------------------------------------------------------------------------

by bamarni at 2012-09-19T16:52:52Z

@stof: in detached head indeed the version can't be guessed with git, so this change avoid potential issues with reciprocal dependencies (I guess it can also be solved by specifying a "version" in composer.json).

But I still don't get why you say branch aliases have nothing to do with the root package version, isn't the purpose of a "2.1-dev" branch-alias to be matched when specifying this package as a dependency with 2.1.*, no matter the branch name or if git is in detached head?

---------------------------------------------------------------------------

by stof at 2012-09-19T18:59:13Z

@bamarni a **branch** alias is about the aliasing the version of a branch. Look at how it is written. It tells composer that for Symfony, the ``dev-master`` version (so the master branch) should receive an alias ``2.2.x-dev``.
This alias will never help you if your root version cannot be guessed as being ``dev-master``.

---------------------------------------------------------------------------

by bamarni at 2012-09-19T20:43:19Z

ahh... in my mind branch alias was only an alias for the current branch, I forgot that it was a 'branch => alias' map, indeed in that case it can't help at all.

thx for the explanations ;)
[Console] fixed default argument display (closes #5563)
[HttpFoundation] removed the username and password from generated URL as generated by the Request class (closes #5555)

Quoted from the ticket it solves for future reference:

"I've been having issues with using htdigest auth (requirement for me to
work with) after upgrading to 2.1. Each time a resource is loaded, a
prompt is given for the HTTP Auth username and password, and Chrome does
not automatically respond to these 401 responses with the credentials it
already has. I've traced the issue to being caused by the HttpFoundation
Component, specifically Request.php.

The request class adds the PHP_AUTH_USER/PHP_AUTH_PW parameters to the
request URI (changes http://www.mysite.com requests to
http://user:pw@www.mysite.com) in getSchemeAndHttpHost(). This behaviour
is not specified in the HTTP RFC, and is incompatible with Chrome as of
Chrome 19, IE (as of IE 9) and has special behaviour in Firefox (prompts
the user to confirm they know they're logging into the site, which is an
ambiguous behaviour at best, but at least it's something if they're
going to support it for now).

This functionality was added about to HttpFoundation about a year ago,
but it really should be removed and standard protocol practices should
be followed. This practice makes it possible for cross-site tracking and
other malicious behaviours to be performed by hiding information in the
authorization headers, which explains why most browsers no longer
support or take exception with it.

The offending line is specifically this. Replacing it with return
$this->getScheme().'://'.$this->getHttpHost(); seems to solve the
problem."
fixed stringification of array objects in RequestDataCollector (closes #5295)
Merge branch '2.0' into 2.1

* 2.0:
  fixed stringification of array objects in RequestDataCollector (closes #5295)
  Fixing config normalisation example in docblock

Conflicts:
	src/Symfony/Bridge/Doctrine/DataCollector/DoctrineDataCollector.php
	src/Symfony/Component/HttpKernel/DataCollector/RequestDataCollector.php
[Config] Fixed tests on Windows
[Filesystem] Fixed tests on Windows
[Console] Fix some input tests
merged branch Nanocom/console_fix_input_tests (PR #5579)

Commits
-------

cc46780 [Console] Fix some input tests

Discussion
----------

[Console] Fix some input tests

New PR for console input tests, was previously on the master branch : https://github.com/symfony/symfony/pull/5567
[Locale] Fixed tests
[Console] Fixed return value for Command::run
merged branch hason/command (PR #5585)

Commits
-------

c869a65 [Console] Fixed return value for Command::run

Discussion
----------

[2.1][Console] Fixed return value for Command::run

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT

API says that Command::run returns integer. This is also necessary if I want to run nested commands.
[Config] Fixed preserving keys in associative arrays