Testing minimal versions of Symfony requirements
December 17, 2014 • Published by Javier Eguiluz
Contributed by
Nicolas Grekas
in #3450.
Setting up Composer package versions for complex projects is not an easy task. For starters, there are a lot of different ways to define package versions. Then, you must check that declared package versions really work when installing or updating the project, specially for the minimal versions configured.
In order to improve testing the minimal versions of Symfony Components requirements, Composer now includes two new options:
--prefer-lowest
: installs the lowest version possible for all dependencies.--prefer-stable
: prefers to install stable versions of dependencies, which means that, when combined with the previous one, using~2.4
version would get2.4.0-stable
over2.4.0-alpha1
.
Thanks to these two new options, it's really easy to check whether your project really works for the minimal package versions declared by it:
1
$ composer update --prefer-lowest --prefer-stable
In Symfony project, checking that minimal versions are correct it's important to ensure backward compatibility for Symfony 2.3 version (which is a long term support version that is very popular to create new Symfony projects) and to ensure forward compatibility with Symfony 3 (which will use some 2.x components).
That's why during the last weeks we've been working hard on fixing all the package version requirements for all components and all Symfony branches. Check out the changes introduced in 2.3 branch, in 2.5 branch and in 2.6 branch (which have been also applied to 2.7 and master branches).
Fixing package versions for private projects and applications it's not worth it, but if you manage any open source project, you should probably fix its package versions. In order to do it, you'll have to follow a trial and error methodology, because this process cannot be easily automated:
- Install your project with the
--prefer-lowest
option and check if there is any error. - Run you test suite and check if there is any error or failure.
- If there is no error, everything is correct. You can optionally try to lower package versions if you want to be as less restrictive as possible.
If there is any error, follow this process:
- Read the error message to find the element that is failing (a class, a function, a method etc.)
- Go to the repository of code for that package and look for that element.
- Execute
git blame
command to find the exact commit that introduced, changed or removed that element. - Look for the minimum tag version which includes that commit. That's the minimum version required for the package!
- Finally, be sure to enforce correct lowest requirements by using your continuous integration server. Check Symfony's .travis.yml file for inspiration.
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
To be exact, Nicolas contributed the --prefer-stable option in the CLI (and all the stuff about prefer-lowest). The prefer-stable feature exists in Composer since March 2012 when configuring it through the composer.json file