Symfony 2.4.0 released
December 3, 2013
•
Published by
Fabien Potencier
Warning: Symfony 2.4 is no longer supported. Consider upgrading your applications to the most recent Symfony version.
Today, we have released Symfony 2.4.0, six months after 2.3.0. As planned in the roadmap, and for the first time of the 2.x branch lifetime, we achieved full backward compatibility; as a matter of fact, the UPGRADE file for 2.4 is empty. That means that upgrading from 2.3 is painless. And even if many projects won't upgrade anytime soon as 2.3 is a long-term support release, let's talk quickly about this new version and all the exiting new features it comes with.
Stats
A quick look at some statistics about 2.4: 493 pull requests, 1,474 commits, 54 developers.
Features
All interesting new changes have been described on this blog during the last few months, but here is the full list:
- Security: Customize the Security Features with ease;
- Security: Restrict Security Firewalls to specific Hosts;
- Stopwatch: A Stopwatch Tag for Twig;
- Debug: Better Error Messages for missing Classes and Functions;
- Debug: Easier debugging of not-found resources;
- Debug: Quicker Access to the Profiler when working on an API;
- DomCrawler: Schema-relative URLs;
- DomCrawler: Namespaces auto-discovery in DowCrawler;
- DomCrawler: Disabling internal Validation of DomCrawler;
- Console: Show logs in console;
- Console: Console improvements;
- Console: Better Console Integration with third-party Tools;
- HttpFoundation: Using Constants for HTTP Status Code;
- HttpFoundation: Limiting Session Metadata Writes;
- HttpFoundation: The Request Stack;
- Config: Dumping the default Configuration for an Extension;
- Process: Limit a Process Run with an idle Timeout;
- Process: Flushing stdout and stderr on a Process;
- Form: Great Form Panel in the Web Profiler;
- Validator: A better Callback constraint;
- Validator: A more powerful image validator;
Symfony 2.4 also comes with a new component, Expression Language.
Upgrading
As I said before, upgrading should be painless and should be a matter of
changing the dependency version in your project composer.json file. We also
recommend to comment or remove the firephp and chromephp Monolog
handlers as they might cause issues with some configuration (chromephp with
Nginx for instance).
Installing
If you are starting a new project on Symfony 2.4, based on the full-stack framework, you have several options:
Create a new project via Composer (recommended):
1
$ php composer.phar create-project symfony/framework-standard-edition somewhere/ 2.4.0- Download an archive for the Symfony Standard Edition;
If you are using some of the Symfony components in your new application, just use the `2.4.0` version or the `2.4` branch:
- Via Composer packages;
- Via Github downloads: https://github.com/symfony/{COMPONENT_NAME}/archive/v2.4.0.zip.
Happy Symfony upgrade!
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.
thanks to everyone involved in this release (code, docs, support, feedback, ...)
great job!
Sweet!
Bravo...
Great job to all contributors!
The documentation stats for 2.4.0 are: 206 commits; 74 file changes and 26 contributors
Also note that you can use 2.4.* in the command, to always get the latest stable 2.4 version.
Nice!
Cool.
Yatta ＼(´・ω・`)／
Nice job!
In this post, the link to "Disabling internal Validation of DomCrawler" is broken.
Great :)
The 2.4 version requires the symfony/icu component, which depends on the lib-icu package. Check that your production server already have this package before considering an upgrade. Is it still a "full backward compatibility" upgrade if it requires a new package?
Oops, that wasn't the real problem, I finally identified it : Symfony 2.3.* used symfony/icu 1.1.* whereas Symfony 2.4.* uses symfony/icu 1.2.*
The problem is that symfony/icu 1.2.* requires an updated lib-icu: 4.4 is required whereas 3.8 was sufficient with Symfony 2.3.*. composer.phar wasn't able to manage the "old" version package, it broke my production website.
I found a solution: I removed the synchronisation of my composer.lock file from the dev server to the prod server. Then the "php composer.phar update --prefer-dist ; php composer.phar install --no-dev --optimize-autoloader --prefer-dist" command worked perfectly.
(you can merge or remove my multiple comments if needed)
Thanks for Symfony!
@Alexis> "Is it still a "full backward compatibility" upgrade if it requires a new package?" Yes it is. If LibreOffice releases a new version only compatible with Ubuntu 13.10+ but still able to open old LibreOffice files, then it is "full backward compatible". In this case, your Symfony 2.3 source code will still work on Symfony 2.4. The fact that some new package should be installed shouldn't be taken in account IMO. ;)
Issue with propelBundle
https://github.com/propelorm/PropelBundle/issues/260
@Alexis the issue with ICU was the same on sf 2.3 If your dev env has the lib ICU >= 4.4 when you run update composer will install Symfony/ICU v1.2.0 and then it won't work on your prod env if the same ICU lib is not provided. The simple way to fix this issue is to add "symfony/icu": "v1.1.0" in your composer requirement, that way it will work on your dev and prod env :)
congratulation for the full backward compatibility (most important thing for me :)), and thank you for this new version...
Thanks to all contributors. I blogged about some of the new features. Maybe you're interested in: http://frankneff.ch/post/69604449524/symfony-2-4-an-overview-of-changes
@Jérémie Augustin : many thanks for the useful tip about ICU ! :)