Yesterday Fabien Potencier post the intriguing news. You can read his post below.
"During the last year, I've been talking about Symfony 3.0 at various conferences. I've been thinking about the best Symfony 3.0 strategy for quite a long time now and it's time to share my thoughts with everyone.
Some developers and most project managers are afraid when major versions of their favourite Open-Source libraries are announced; probably because major versions are associated with backward incompatible changes. Many questions arise: Will the changes bring significant value for my project? Is the roadmap clear enough to anticipate the upgrade? Will it be easy/possible to upgrade? What if I don't want or cannot upgrade now? And then some more.
The fear of major new versions is based on bad experiences from the past: think about Perl 6 or PHP 6. In the Symfony world, Symfony 2 was also a big revolution as it is very different from symfony 1. I realise that talking about Symfony 3 makes people nervous and this post is going to explain the Symfony 3 strategy and the reasons why you should not panic.
First, everyone knows that major versions need to happen on a regular basis. We need to be able to break backward compatibility to remove obsolete features, fix architecture mistakes, and take into account the changes in the ecosystem: PHP's new capabilities, best practice changes, new web paradigms, ... The Internet evolves at a very fast pace and if we cannot adapt Symfony fast enough, it will become irrelevant faster than you can imagine.
As the project manager of Symfony, one of my responsibility is it to keep the code as stable as possible for as long as possible. But stability does not mean status quo: we do add new features and we do fix architecture mistakes in minor versions as you can see for yourself in Symfony 2.4, 2.5, and 2.6. All those versions come with major new features and each of them is a great step forward for the framework. But upgrading is very easy because backward compatibility is kept with older versions. The challenge is the maintenance of the backward compatibility layer for obsolete or deprecated features (and I'm not even talking about the performance penalty we need to minimize.) It has been quite easy for Symfony2 as it is based on a very solid foundation made of decoupled components. By the definition of semantic versioning, a new major version is "just" a milestone where we can clean things up and get rid of the cruft.
What is Symfony 3.0?
Because new features are added all the time in minor versions and because some others are deprecated, you can start to make your code "more compatible" with 3.0 today. Read the upgrade guide for Symfony 3.0 and make the optional suggested changes; that allows you to plan the migration ahead of time at your own pace.
As you might have guessed by now, Symfony 3.0 is not going to be a revolution and the low-level architecture of the framework won't change. Here are some simple examples of changes we made in Symfony 2.x that will make Symfony 3.0 better:
Symfony 3.0 is more standard (usage of PSR-3 for logging and the removal of theSymfonyComponentHttpKernelLogLoggerInterface interface, ...)
Symfony 3.0 fixes some architecture mistakes (stateful console helpers are removed in favour of better alternatives (ProgressBar vs ProgressHelper or Table vs TableHelper; Yaml::parse() does not support file names anymore, ...)
Symfony 3.0 is more decoupled and more reusable than ever (the HttpKernel is going to be split into several smaller ones -- the profiler for instance will be standalone; classes are moved from bundles to components; components are extracted from existing ones, ...)
The Symfony 3.0 Schedule
Avoiding the drama about new major versions is also made easier by communicating often and early. That's why the Symfony community has been hard at work to document our strategy: From the backward compatibility promise to the version roadmap and LTS releases.
One way to minimize the impact of new versions is to also make them predictable. According to our roadmap, Symfony 2.7, to be released in May 2015, will be the next long term support release, 2.7 will be maintained until May 2018 for bug fixes and May 2019 for security ones. Instead of planning a 2.8 after 2.7, I propose to make the jump straight to 3.0. So, Symfony 3.0 will be released in November 2015 and the first 3.x long term release will be 3.3 to be released in May 2017.
The interactive Symfony Roadmap has been updated to take the Symfony 3.x branch into account.
What should you do? As explained in the release process documentation chapter, there are two upgrade strategies:
"The dual maintenance mode was adopted to make every Symfony user happy. Fast movers, who want to work with the latest and the greatest, use the standard version: a new version is published every six months, and there is a two months period to upgrade. Companies wanting more stability use the LTS versions: a new version is published every two years and there is a year to upgrade."
Where is Symfony 3.0?
To make it easy for everyone to start contributing to Symfony 3.0 today, the master branch of the main repository now hosts the Symfony 3.0 code; a 2.6 and a 2.7 branches have been created for these upcoming versions.
If your project is using the Symfony master branch to follow the latest 2.x evolutions, consider switching to the 2.7 branch today.
The merge strategy will be almost the same as it is currently, with some slight differences:
New features will be merged in 2.7 if they do not break backward compatibility or if they do not impact existing code;
New features will only be merged in 3.0 if there is no way to make them work in the 2.7 branch;
Bug fixes will still be merged in the oldest and still maintained branch and will be merged back to newer versions on a regular basis, including the master (aka 3.0) branch.
How can you help?
There are a lot of easy changes that can to be done for Symfony 3.0 today. First, all deprecated features need to generate deprecated logs in the 2.7 branch (like what we did before the 2.3 release.) Then, everything deprecated must be removed in the master branch. Finally, the upgrade guide should be tested and augmented to make the upgrade process as easy as possible for everyone. You can also have a look at the issues specifically tagged as 3.0 on Github.