Use a bound constraint and right package for the doctrine annotations

[stof]

Installing the full doctrine/common package is not necessary when only doctrine/annotations is used

[Ocramius]

@stof thanks!

master: aa96152
develop: b980379

[stof]

@Ocramius I have another question regarding the dev requirements. Why is PHP-CS-Fixer fixed at 1.7.* which is very old ? Many thing have been fixed in later minor versions

[Ocramius]

@stof we've been bitten many times by CS fixer minor versions, although the maintainer became more careful. We may as well bump it (via ^) now.

[Maks3w]

1. PHP-CS-Fixer has not being BC Safe (too many changes in the default fixers)
2. We are replacing now with PHPCS

[Ocramius]

We are replacing now with PHPCS

Wasn't aware of this - the author of the cs fixer seemed to be very collaborative/helpful, no?

[Maks3w]

I know. @weierophinney started to use phpcs for all v3 refactors.

[weierophinney]

@Ocramius I have several reasons for switching to phpcs:

• It's tremendously faster, both for verifying CS as well as fixing CS issues.
• When using the PSR-2 ruleset, it validates and fixes only those. php-cs-fixer's PSR-2 ruleset is a superset of its default ruleset, which does substantially more, most of which are things we do not actually want, which means we have to have incredibly large configuration files to exclude things. Additionally, the maintainers of php-cs-fixer keep adding rules to the default ruleset, which is what bites us periodically (new rules then mark code as invalid, despite the fact that it's adhering to PSR-2).

In terms of the authors being collaborative, I've found the phpcs folks to be equally responsive when I've raised issues. As such, it's the latter bullet point that has been the deciding factor for me. Two subsequent runs of the tool over the same code should not raise new errors between versions of the tool.

[weierophinney]

@Ocramius Did you tag 2.6.1?

[Ocramius]

@weierophinney nope, just assigned the milestone