About symfony 3.0
Over the past year, I have talked a lot about Symfony 3.0 at various conferences. I thought about the best strategy for this version a long time ago, and now it is time to share my thoughts with everyone.
Some developers and most project managers fear major versions of the open source projects they use. This is probably due to the fact that major versions are associated with the loss of backward compatibility. Many questions arise: will the changes benefit my project? Are the developers' plans clear enough to make sense of updating? Will the update be easy? What if I can’t or don’t want to be updated? And so on.
The fear of major versions grows from our past: remember Perl 6 or PHP 6. In the Symfony world, the second version was also revolutionary compared to symfony 1. I understand why people are nervous when they hear about the third version, and it is in this post I will tell you why you do not need to panic.
First of all, everyone knows that updates of both major and minor versions should occur regularly. We need to be able to break backward compatibility in order to remove irrelevant functionality, fix architecture errors and take into account changes in the ecosystem, such as new PHP features, new development methodologies, new web paradigms. The Internet environment is evolving very quickly, and if we do not adapt Symfony to it, it will become irrelevant much faster than you think.
')
As a symfony project manager, I am responsible for ensuring that the code is as stable as possible for as long as possible. But stability is not a status quo: we add features and fix architectural flaws in minor releases, as you can see from the examples of versions 2.4 , 2.5 and 2.6 . All these versions added functionality to the framework, and each of them was a noticeable step forward for the framework itself. But it was simply updated due to the fact that backward compatibility was maintained . The problem is in maintaining backward compatibility for obsolete or irrelevant features (and I'm not even talking about performance!). For symfony 2, this was easy enough because it is built on a solid base of independent components. By the definition of semantic versioning , the new major version is just another step at which we can clean up the code and get rid of the trash.
What is symfony 3.0?
Since new features are constantly being added in minor versions, and outdated ones are marked as such, you can start to improve the compatibility of your code with Symfony 3.0 today. Read the upgrade guide and complete the proposed changes, this will allow you to prepare for migration in advance.
As you probably already guessed, in Symfony 3.0, the low-level architecture will not drastically change , and the release will not be revolutionary. Here are examples of some of the changes in symfony 2.x that will make 3.0 even better:
It is possible to avoid panic over new major versions if you report your intentions as early as possible. That's precisely why the Symfony community has so carefully documented our strategy, from promises of backward compatibility to roadmap and releases with enhanced support.
One way to minimize the fear of new versions is to make them predictable. According to our release schedule, Symfony 2.7, which is due for release in May 2015, will be the next release with continued support, which will last until May 2018 via bugfixes and until May 2019 for security updates. Instead of planning to follow 2.8, I propose to skip straight to 3.0. So 3.0 will be released in November 2015, and the first release with extended support in the 3.x branch will be 3.3, which will be released in May 2017.
The interactive release schedule has also been updated to include branch 3.0.
What do you do? According to the release process documentation chapter , there are two update strategies:
To make it easier for everyone to help develop Symfony 3.0 right now, the master branch of the main repository is now set aside for 3.0, and for 2.6 and 2.7 we created separate branches.
If your project uses a symfony master branch to monitor 2.x development, switch to 2.7 today.
The strategy for merging changes will be almost the same as now, with the exception of some changes:
Finally, what about the minimal version of PHP? A few days ago I conducted a survey on this topic, and the results are as follows:
Based on these results, I propose to make PHP 5.5 the minimum supported version for Symfony 3.0. I want to keep the opportunity to raise this requirement to PHP 5.6 somewhere next year, but the exact date will depend on our needs and support for the new version of hosters and OS distributions.
There are many simple changes that can be implemented in symfony 3.0 today. First of all, in the 2.7 branch, all outdated features should report themselves to the log. In the master branch, these features should be removed. Finally, the upgrade guide should be tested and refined so that it is easy and simple to update. You can also look at tickets running as 3.0 on Github .
Have a nice code!
Major versions
Some developers and most project managers fear major versions of the open source projects they use. This is probably due to the fact that major versions are associated with the loss of backward compatibility. Many questions arise: will the changes benefit my project? Are the developers' plans clear enough to make sense of updating? Will the update be easy? What if I can’t or don’t want to be updated? And so on.
The fear of major versions grows from our past: remember Perl 6 or PHP 6. In the Symfony world, the second version was also revolutionary compared to symfony 1. I understand why people are nervous when they hear about the third version, and it is in this post I will tell you why you do not need to panic.
First of all, everyone knows that updates of both major and minor versions should occur regularly. We need to be able to break backward compatibility in order to remove irrelevant functionality, fix architecture errors and take into account changes in the ecosystem, such as new PHP features, new development methodologies, new web paradigms. The Internet environment is evolving very quickly, and if we do not adapt Symfony to it, it will become irrelevant much faster than you think.
')
As a symfony project manager, I am responsible for ensuring that the code is as stable as possible for as long as possible. But stability is not a status quo: we add features and fix architectural flaws in minor releases, as you can see from the examples of versions 2.4 , 2.5 and 2.6 . All these versions added functionality to the framework, and each of them was a noticeable step forward for the framework itself. But it was simply updated due to the fact that backward compatibility was maintained . The problem is in maintaining backward compatibility for obsolete or irrelevant features (and I'm not even talking about performance!). For symfony 2, this was easy enough because it is built on a solid base of independent components. By the definition of semantic versioning , the new major version is just another step at which we can clean up the code and get rid of the trash.
What is symfony 3.0?
Since new features are constantly being added in minor versions, and outdated ones are marked as such, you can start to improve the compatibility of your code with Symfony 3.0 today. Read the upgrade guide and complete the proposed changes, this will allow you to prepare for migration in advance.
As you probably already guessed, in Symfony 3.0, the low-level architecture will not drastically change , and the release will not be revolutionary. Here are examples of some of the changes in symfony 2.x that will make 3.0 even better:
- Compatibility with standards has been improved (we use the logger from PSR-3 and removed the interface Symfony \ Component \ HttpKernel \ Log \ LoggerInterface)
- Symfony 3.0 fixes some architectural errors (state-supported console helpers are replaced by better alternatives, for example ProgressBar / ProgressHelper or Table / TableHelper; Yaml :: parse () no longer accepts file names)
- Symfony 3.0 is even more distributed and reusable. HttpKernel will be divided into several smaller modules, for example, the profiler will be separated, classes will be moved from bundles to components, components will be separated from existing ones ...)
Symfony 3.0 release schedule
It is possible to avoid panic over new major versions if you report your intentions as early as possible. That's precisely why the Symfony community has so carefully documented our strategy, from promises of backward compatibility to roadmap and releases with enhanced support.
One way to minimize the fear of new versions is to make them predictable. According to our release schedule, Symfony 2.7, which is due for release in May 2015, will be the next release with continued support, which will last until May 2018 via bugfixes and until May 2019 for security updates. Instead of planning to follow 2.8, I propose to skip straight to 3.0. So 3.0 will be released in November 2015, and the first release with extended support in the 3.x branch will be 3.3, which will be released in May 2017.
The interactive release schedule has also been updated to include branch 3.0.
What do you do? According to the release process documentation chapter , there are two update strategies:
Dual support mode was designed to make every symfony user happy. For those who want to work with the freshest and coolest, there is a standard version that comes out every six months, and two months are allocated for the update. For those who need stability, there is an enhanced support version: a new version is released every two years, and a year is given for renewal.
Where to get symfony 3.0?
To make it easier for everyone to help develop Symfony 3.0 right now, the master branch of the main repository is now set aside for 3.0, and for 2.6 and 2.7 we created separate branches.
If your project uses a symfony master branch to monitor 2.x development, switch to 2.7 today.
The strategy for merging changes will be almost the same as now, with the exception of some changes:
- New functionality will be added in 2.7, if it does not lead to loss of compatibility, or if changes do not affect the existing code
- New features will be added in 3.0, if there is no way to make them work in 2.7
- Bug fixes will continue to be added to the oldest supported branch and to new branches (and 3.0 too) regularly
Minimal PHP version for symfony 3.0
Finally, what about the minimal version of PHP? A few days ago I conducted a survey on this topic, and the results are as follows:
Based on these results, I propose to make PHP 5.5 the minimum supported version for Symfony 3.0. I want to keep the opportunity to raise this requirement to PHP 5.6 somewhere next year, but the exact date will depend on our needs and support for the new version of hosters and OS distributions.
How to help?
There are many simple changes that can be implemented in symfony 3.0 today. First of all, in the 2.7 branch, all outdated features should report themselves to the log. In the master branch, these features should be removed. Finally, the upgrade guide should be tested and refined so that it is easy and simple to update. You can also look at tickets running as 3.0 on Github .
Have a nice code!
Source: https://habr.com/ru/post/242915/
All Articles