|
| 1 | +.. index:: |
| 2 | + single: Upgrading; Bundle; Major Version |
| 3 | + |
| 4 | +Upgrading a Third-Party Bundle for a Major Symfony Version |
| 5 | +========================================================== |
| 6 | + |
| 7 | +Symfony 3 was released on November 2015. Although this version doesn't contain |
| 8 | +any new feature, it removes all the backwards compatibility layers included in |
| 9 | +the previous 2.8 version. If your bundle uses any deprecated feature and it's |
| 10 | +published as a third-party bundle, applications upgrading to Symfony 3 will no |
| 11 | +longer be able to use it. |
| 12 | + |
| 13 | +Allowing to Install Symfony 3 Components |
| 14 | +---------------------------------------- |
| 15 | + |
| 16 | +Most third-party bundles define their Symfony dependencies using the ``~2.N`` or |
| 17 | +``^2.N`` constraints in the ``composer.json`` file. For example: |
| 18 | + |
| 19 | +.. code-block:: json |
| 20 | +
|
| 21 | + { |
| 22 | + "require": { |
| 23 | + "symfony/framework-bundle": "~2.3", |
| 24 | + "symfony/finder": "~2.3", |
| 25 | + "symfony/validator": "~2.3" |
| 26 | + } |
| 27 | + } |
| 28 | +
|
| 29 | +These constraints prevent the bundle from using Symfony 3 components, so it makes |
| 30 | +it impossible to install it in a Symfony 3 based application. This issue is very |
| 31 | +easy to solve thanks to the flexibility of Composer dependencies constraints. |
| 32 | +Just replace ``~2.N`` by ``~2.N|~3.0`` (or ``^2.N`` by ``^2.N|~3.0``). |
| 33 | + |
| 34 | +The above example can be updated to work with Symfony 3 as follows: |
| 35 | + |
| 36 | +.. code-block:: json |
| 37 | +
|
| 38 | + { |
| 39 | + "require": { |
| 40 | + "symfony/framework-bundle": "~2.3|~3.0", |
| 41 | + "symfony/finder": "~2.3|~3.0", |
| 42 | + "symfony/validator": "~2.3|~3.0" |
| 43 | + } |
| 44 | + } |
| 45 | +
|
| 46 | +.. tip:: |
| 47 | + |
| 48 | + Another common version constraint found on third-party bundles is ``>=2.N``. |
| 49 | + You should avoid using that constraint because it's too generic (it means |
| 50 | + that your bundle is compatible with any future Symfony version). Use instead |
| 51 | + ``~2.N|~3.0`` or ``^2.N|~3.0`` to make your bundle future-proof. |
| 52 | + |
| 53 | +Looking for Deprecations and Fix Them |
| 54 | +------------------------------------- |
| 55 | + |
| 56 | +Besides allowing to install Symfony 3 packages, your bundle must stop using |
| 57 | +any feature deprecated in 2.8 version, because they are removed (and you'll get |
| 58 | +exceptions or PHP errors). The easiest way to detect deprecations is to install |
| 59 | +the `symfony/phpunit-bridge package`_ and then run the test suite. |
| 60 | + |
| 61 | +First, install the component as a ``dev`` dependency of your bundle: |
| 62 | + |
| 63 | +.. code-block:: bash |
| 64 | +
|
| 65 | + $ composer require --dev symfony/phpunit-bridge |
| 66 | +
|
| 67 | +Then, run your test suite and look for the deprecation list displayed after the |
| 68 | +PHPUnit test report: |
| 69 | + |
| 70 | +.. code-block:: bash |
| 71 | +
|
| 72 | + $ phpunit |
| 73 | +
|
| 74 | + # ... PHPUnit output |
| 75 | +
|
| 76 | + Remaining deprecation notices (3) |
| 77 | +
|
| 78 | + The "pattern" option in file ... is deprecated since version 2.2 and will be |
| 79 | + removed in 3.0. Use the "path" option in the route definition instead ... |
| 80 | +
|
| 81 | + Twig Function "form_enctype" is deprecated. Use "form_start" instead in ... |
| 82 | +
|
| 83 | + The Symfony\Component\Security\Core\SecurityContext class is deprecated since |
| 84 | + version 2.6 and will be removed in 3.0. Use ... |
| 85 | +
|
| 86 | +Fix the reported deprecations, run the test suite again and repeat the process |
| 87 | +until no deprecation usage is reported. |
| 88 | + |
| 89 | +Useful Resources |
| 90 | +~~~~~~~~~~~~~~~~ |
| 91 | + |
| 92 | +There are several resources that can help you detect, understand and fix the use |
| 93 | +of deprecated features: |
| 94 | + |
| 95 | +`Official Symfony Guide to Upgrade from 2.x to 3.0`_ |
| 96 | + The full list of changes required to upgrade to Symfony 3.0 and grouped |
| 97 | + by component. |
| 98 | +`SensioLabs DeprecationDetector`_ |
| 99 | + It runs a static code analysis against your project's source code to find |
| 100 | + usages of deprecated methods, classes and interfaces. It works for any PHP |
| 101 | + application, but it includes special detectors for Symfony applications, |
| 102 | + where it can also detect usages of deprecated services. |
| 103 | +`Symfony Upgrade Fixer`_ |
| 104 | + It analyzes Symfony projects to find deprecations. In addition it solves |
| 105 | + automatically some of them thanks to the growing list of supported "fixers". |
| 106 | + |
| 107 | +Testing your Bundle in Symfony 3 |
| 108 | +-------------------------------- |
| 109 | + |
| 110 | +Now that your bundle has removed all deprecations, it's time to test it for real |
| 111 | +in a Symfony 3 application. Assuming that you already have a Symfony 3 application, |
| 112 | +you can test the updated bundle locally without having to install it through |
| 113 | +Composer. |
| 114 | + |
| 115 | +If your operating system supports symbolic links, just point the appropriate |
| 116 | +vendor directory to your local bundle root directory: |
| 117 | + |
| 118 | +.. code-block:: bash |
| 119 | +
|
| 120 | + $ ln -s /path/to/your/local/bundle/ vendor/you-vendor-name/your-bundle-name |
| 121 | +
|
| 122 | +If your operating system doesn't support symbolic links, you'll need to copy |
| 123 | +your local bundle directory into the appropriate directory inside ``vendor/``. |
| 124 | + |
| 125 | +Update the Travis CI Configuration |
| 126 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 127 | + |
| 128 | +In addition to running tools locally, it's recommended to set-up Travis CI service |
| 129 | +to run the tests of your bundle using different Symfony configurations. Use the |
| 130 | +following recommended configuration as the starting point of your own configuration: |
| 131 | + |
| 132 | +.. code-block:: yaml |
| 133 | +
|
| 134 | + language: php |
| 135 | + sudo: false |
| 136 | + php: |
| 137 | + - 5.3 |
| 138 | + - 5.6 |
| 139 | + - 7.0 |
| 140 | +
|
| 141 | + matrix: |
| 142 | + include: |
| 143 | + - php: 5.3.3 |
| 144 | + env: COMPOSER_FLAGS='--prefer-lowest --prefer-stable' SYMFONY_DEPRECATIONS_HELPER=weak |
| 145 | + - php: 5.6 |
| 146 | + env: SYMFONY_VERSION='2.3.*' |
| 147 | + - php: 5.6 |
| 148 | + env: DEPENDENCIES='dev' SYMFONY_VERSION='2.8.*@dev' |
| 149 | + - php: 5.6 |
| 150 | + env: SYMFONY_VERSION='3.0.*@dev' |
| 151 | +
|
| 152 | + before_install: |
| 153 | + - composer self-update |
| 154 | + - if [ "$DEPENDENCIES" == "dev" ]; then perl -pi -e 's/^}$/,"minimum-stability":"dev"}/' composer.json; fi; |
| 155 | + - if [ "$SYMFONY_VERSION" != "" ]; then composer --no-update require symfony/symfony:${SYMFONY_VERSION}; fi; |
| 156 | +
|
| 157 | + install: composer update $COMPOSER_FLAGS |
| 158 | +
|
| 159 | + script: phpunit |
| 160 | +
|
| 161 | +Updating your Code to Support Symfony 2.x and 3.x at the Same Time |
| 162 | +------------------------------------------------------------------ |
| 163 | + |
| 164 | +The real challenge of adding Symfony 3 support for your bundles is when you want |
| 165 | +to support both Symfony 2.x and 3.x simultaneously using the same code. There |
| 166 | +are some edge cases where you'll need to deal with the API differences. |
| 167 | + |
| 168 | +Before diving into the specifics of the most common edge cases, the general |
| 169 | +recommendation is to **not rely on the Symfony Kernel version** to decide which |
| 170 | +code to use:: |
| 171 | + |
| 172 | + if (Kernel::VERSION_ID <= 20800) { |
| 173 | + // code for Symfony 2.x |
| 174 | + } else { |
| 175 | + // code for Symfony 3.x |
| 176 | + } |
| 177 | + |
| 178 | +Instead of checking the Symfony Kernel version, check the version of the specific |
| 179 | +component. For example, the OptionsResolver API changed in its 2.6 version by |
| 180 | +adding a ``setDefined()`` method. The recommended check in this case would be:: |
| 181 | + |
| 182 | + if (!method_exists('Symfony\Component\OptionsResolver\OptionsResolver', 'setDefined')) { |
| 183 | + // code for the old OptionsResolver API |
| 184 | + } else { |
| 185 | + // code for the new OptionsResolver API |
| 186 | + } |
| 187 | + |
| 188 | +Form Name Refactoring |
| 189 | +~~~~~~~~~~~~~~~~~~~~~ |
| 190 | + |
| 191 | +.. TODO |
| 192 | +
|
| 193 | + - how to check which version to use |
| 194 | + - how to update FormType classes |
| 195 | + - how to update type service definitions |
| 196 | + - how to update FormTypeExtension classes & service definition |
| 197 | +
|
| 198 | +OptionsResolver API Refactoring |
| 199 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 200 | + |
| 201 | +.. TODO |
| 202 | +
|
| 203 | + - how to check which version to use |
| 204 | + - how to both APIs |
| 205 | +
|
| 206 | +Service Factory Refactoring |
| 207 | +~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 208 | + |
| 209 | +.. TODO |
| 210 | +
|
| 211 | + - how to support both APIs ==> Is there a nice way except from (a) doing |
| 212 | + it in the DI extension or (b) creating 2 service definition files? |
| 213 | +
|
| 214 | +.. _`symfony/phpunit-bridge package`: https://github.com/symfony/phpunit-bridge |
| 215 | +.. _`Official Symfony Guide to Upgrade from 2.x to 3.0`: https://github.com/symfony/symfony/blob/2.8/UPGRADE-3.0.md |
| 216 | +.. _`SensioLabs DeprecationDetector`: https://github.com/sensiolabs-de/deprecation-detector |
| 217 | +.. _`Symfony Upgrade Fixer`: https://github.com/umpirsky/Symfony-Upgrade-Fixer |
0 commit comments