Update src/Symfony/Component/Validator/Mapping/ClassMetadataFactory.php
NativeRedisSessionStorage added

- fix and simple unit test added
Native Redis Session Storage update
doc fix
merged branch pulzarraider/session_doc_fix (PR #3627)

Commits
-------

f351cdc doc fix

Discussion
----------

[HttpFoundation] documentation fix

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
merged branch pulzarraider/webprofiler_serch_ipv6_fix (PR #3626)

Commits
-------

54b2413 Webprofiler ipv6 search fix

Discussion
----------

[WebProfilerBundle] ipv6 search fix

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
merged branch nodrew/2.0 (PR #3625)

Commits
-------

8642473 Changed instances of \DateTimeZone::UTC to 'UTC' as the constant is not valid a produces this error when DateTimeZone is instantiated: DateTimeZone::__construct() [<a href='datetimezone.--construct'>datetimezone.--construct</a>]: Unknown or bad timezone (1024)

Discussion
----------

[Locale] DateTimeZone called incorrectly by default

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: no (there were two tests that were failing previously, that still fail)
Fixes the following tickets: none
Todo: none

While running, a warning throws every single time when the code

```php
new \DateTimeZone(\DateTimeZone::UTC);
```
is encountered. It is normally caught as a thrown exception and then corrected here:

```php
// src/Symfony/Component/Locale/Stub/StubIntlDateFormatter.php:442
        try {
            $this->dateTimeZone = new \DateTimeZone($timeZoneId);
        } catch (\Exception $e) {
            $this->dateTimeZone = new \DateTimeZone('UTC');
        }
```

However in my particular infrastructure, for whatever reason in production only, it causes an error to appear on shutdown in the logs. As ultimately the constant can NEVER pass, it should not be attempted with the constant. Instead, the correct 'UTC' should be passed in (as done in the catch statement).
[Process] Fix command escaping
merged branch jmikola/double-dash (PR #3624)

Commits
-------

4d4ef24 [Console] Stop parsing options after encountering "--" token

Discussion
----------

[Console] Stop parsing options after encountering "--" token

This enables support for arguments with leading dashes (e.g. "-1"), as supported by getopt in other languages.

[![Build Status](https://secure.travis-ci.org/jmikola/symfony.png?branch=double-dash)](http://travis-ci.org/jmikola/symfony)

The test suite currently fails due to 7a54fe41caf66f468e80c103092b3534348c486a. ArgvInputTest passes, and these changes don't appear to break anything else.

![](http://media.giantbomb.com/uploads/2/27528/1061704-mario_kart_double_dash___title_screen_super.jpg)

Aside: This got me thinking about how one would pass an option value of "-1". I suppose for input options with `VALUE_OPTIONAL`, it would be ambiguous if "-1" followed; however, `VALUE_REQUIRED` should probably require that the next token is captured as the option value. In my tests, a required option value with a leading dash was interpreted as another option. The workaround for all of this is to use the space-less syntax (e.g. `-f=-1`).

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

by fabpot at 2012-03-17T08:43:15Z

AFAIK, the `--` should disable both option and argument parsing, no?

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

by jmikola at 2012-03-18T02:13:51Z

If that were the case, what would be the point of using `--` at all? :)

 * http://wiki.bash-hackers.org/dict/terms/end_of_options
 * http://perldoc.perl.org/Getopt/Long.html#Mixing-command-line-option-with-other-arguments
merged branch blahy/code-coverage-fix (PR #3617)

Commits
-------

9ed7c03 fixed code coverage raport generation

Discussion
----------

fixed code coverage raport generation

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: no (tests were already broken)
Fixes the following tickets: -
Todo: -

I wanted to run the test coverage for Symfony2.1.
I installed vendors using composer but code coverage script failed (running unit tests failed too).
After installing vendors using vendors.php I got errors about missing classes:
`Class 'Doctrine\Common\DataFixtures\Loader' not found`
and later: `Class 'Monolog\Handler\ChromePHPHandler' not found.`

The changes made it possible to run the code coverage script.
Monolog was already present in autoload.php.dist but was not present in vendors.php script, doctrine fixtures were not included in both.
updated vendors for 2.0.12
updated CHANGELOG for 2.0.12
update CONTRIBUTORS for 2.0.12
updated VERSION for 2.0.12
bumped Symfony version to 2.0.13-DEV
added a configurable extension base class
added an exception for failed processes
Improved feedback for Upload Validator to cover all PHP error states.
This way we don't get a unclear "upload error" message unless its something completely unexpected.
removed obsolete phpdoc
add JSONP support to JsonResponse