Hi I strongly +1 this :-).
-- Jérôme VIEILLEDENT 2012/9/17 Fabien Potencier <[email protected]> > My keynote last week at Symfony Live London was about adopting a formal > release process. In fact, I've talked about adopting a shorter release > cycle for Symfony for quite some time now, and I think that this is the > right time to discuss it. > > As we have all noticed, Symfony enjoys a large community of "core" > developers: a core developer being someone who contribute to Symfony on a > regular basis. The flow of pull requests has been outstanding and steady > for the past two years, and with such an activity, trying to release often > without a clear roadmap is quite difficult. Adopting a more formal release > cycle will also give more visibility to the contributors and allow for > everyone to understand when a new feature might be available in Symfony. > > So, here is my initial proposal, which is the one I've talked about during > Symfony Live and of course, it is up for discussion. I would like to apply > the new release process as soon as possible and if possible for Symfony > 2.2. And whenever we all agree on the final version of this proposal, it > will be included in the official Symfony documentation. > > This release process only applies to the code hosted on the > symfony/symfony repository, but of course, I hope that third-party code > related to Symfony (like the Symfony bundles) will also adopt it (at least, > just for the timeline). > > Let's list the goals for the new process: > > * Shorten the release cycle; > > * Keep backward compatibility as much as possible; > > * Enhance the overall quality of the framework (not just the code, but > documentation, bundles, ...); > > * Give more visibility to our "customers": developers using the framework > to get their job done and Open-Soure projects using/embedding Symfony; > > * Improve the experience of Symfony core contributors by controlling the > flow of incoming pull requests (why pull requests are not always merged > right away? when will a new feature be merged? when breaking BC is > acceptable? ...); > > * Coordinate our timeline with projects that we are using (Doctrine, > Propel, Monolog, Assetic, Twig, ...) but also with projects that are > using/embedding Symfony; > > * Give time to the Symfony ecosystem to catch up with the new versions > (bundleauthors, documentation writers, translators, ...); > * Allow developers to benefit from the new features faster. > > That's a lot to take care of! > > So, without further ado, here is my plan. > > Timeline > -------- > > Historically, we've been able to release a new major version every year > since 2005. Nothing was even written about that, but that's what we did. > > From now on, I propose to adopt a *time-based model* for Symfony and I > think that having a new major release every six months is a good > compromise: it gives plenty of time to work on new features but it also > allows for non-ready features to be postponed to the next version (without > having to wait too much for the next cycle). > > Six months should be fast enough for developers who want to work on the > latest and the greatest; but at the same time, companies might want more > time to learn and upgrade. The way to make everyone happy is to ensure an > easy upgrade path from one version to the next one. Take Twig as an > example: I've been able to release a new major version every month and a > half since 1.0; that's very fast and it has been possible because we've > kept backward compatibility between all major releases (and of course the > scope of Twig is also smaller). > > Six month releases mean that two releases fit in a year and so, everybody > knows when releases will be made without having to check on the website: > for Symfony it will be at the end of May and at the end of November of each > year. That brings predictability and visibility. > > The key is keeping backward compatibility. We must be much more careful > when breaking backward compatibility; and the possibility to break backward > compatibility depends on the component we are talking about. The following > components must never break backward compatibility because they are the > low-level architecture of the framework and also because so many people > rely on them: > > * ClassLoader > * Console > * DependencyInjection > * EventDispatcher > * HttpFoundation > * HttpKernel > * Routing > > Backward compatibility should be easy to keep for the following components: > > * BrowserKit > * CssSelector > * DomCrawler > * Filesystem > * Finder > * Locale > * OptionsResolver > * Process > * Templating > * Yaml > > And these components should probably become more stable soon, but that's > not that easy (yet): > > * Config > * Form > * Security > * Serializer > * Translation > * Validator > > Six months can be seen as a rather short period to make a new release, > especially if we look at what we did in the past. I think we can make it > work because we have now more people able to help, but also because the six > month period itself should be cut in shorter periods: > > * Development: 4 months to add new features and to enhance existing ones; > > * Stabilisation: 2 months to fix bugs, prepare the release, and wait for > the whole ecosystem to catch up. > > During the development phase, we can revert any new feature if we think > that we won't be able to finish it in time or if we think that it won't be > stable enough to be included. > > During the stabilisation phase, some developers might still work on new > features for the next version, but it would be better if most developers > can concentrate on finishing the current version. > > By the way, when I have a look at the pull requests today, I think that we > already have enough features for Symfony 2.2. > > Long Term Support release > ------------------------- > > We've not yet published our LTS release for Symfony2. As I mentioned it in > the past, the first LTS should be Symfony 2.3. > > Each LTS release will be supported for a 3 year period but it will also be > supported for at least a year after the next LTS is released. So, it means > that we are going to release a new LTS version every two years. > > This dual release cycle should make everyone happy. If you are a fast > mover, you want to work with the latest and the greatest, stick with the > standard support releases: you have a new version every six months, and you > have two months to upgrade to the next one. If you are a big company, and > you want more stability, stick with the long term support releases: you get > a new version every two years and you have a year to upgrade. > > Schedule > -------- > > To make things more concrete, here is the schedule for the next few > versions: > > * Symfony 2.2 will be released at the end of February 2013; > > * Symfony 2.3 (the first LTS) will be released at the end of Mai 2013 > (only 3 months after 2.2 as it will be a "special" release in the sense > that we will mainly remove the 2.0 BC layer and also because I think that > May and November are the best months for releases); > > * Symfony 2.4 will be released at the end of November 2013; > > * Symfony 2.5 will be released at the end of Mai 2014; > > * ... > > So, why not releasing Symfony 2.2 earlier as we already have so many > features waiting in the pull request queue? Because of the next section: > this is our last chance to break backward compatibility. > > Symfony 3.0 > ----------- > > After the release of Symfony 2.3, backward compatibility will be kept at > all cost. If it is not possible, the feature/enhancement will be scheduled > for Symfony 3.0. And the work on 3.0 will start whenever we think that we > have enough great features under our belt to make it worth it. > > Maintenance > ----------- > > After Symfony 2.3, non LTS releases will be maintained for 8 months to > give people plenty of time to upgrade (keep in mind that even if no BC > breaks will have occurred, you might need to upgrade your applications to > benefit from the new features and the new best practices). > > Contributions > ------------- > > To make the new process works well (no BC and a fixed schedule), we need > to formalise the contribution process a bit more. Every new Symfony feature > or enhancement must be worked on via Git pull requests. A few months ago, > we formalised the pull request process a bit by adding a required [header]( > http://symfony.com/**doc/current/contributing/code/** > patches.html#make-a-pull-**request)/check<http://symfony.com/doc/current/contributing/code/patches.html#make-a-pull-request)/check>list. > But I've done a poor job in enforcing the rule. So, I'm going to be > uncompromising about it now and at the same time I'd like to introduce even > more checks in the list. > > A pull request will only be merged if the following rules are met: > > * The code is correct and it uses the Symfony way of doing things (naming > conventions, coding standards, ...); > > * The new code is tested (or the bug to fix is covered by tests) and all > the tests pass on all supported PHP versions; > > * The documentation has been updated (with a pending pull request on > symfony/symfony-docs); > > * The changelog and upgrade files have been updated; > > * No backward compatibility break has been introduced; > > * If it is a fix, it has been applied to the oldest and still supported > Symfony version; > > * For major features, a RFC has been written, discussed, and approved. > > As I said at the beginning, this is a draft, and you are all welcome to > chime in and propose changes. > > > -- > Fabien Potencier > Sensio CEO - Symfony lead developer > sensiolabs.com | symfony.com | fabien.potencier.org > Tél: +33 1 40 99 80 80 > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > symfony-devs+unsubscribe@**googlegroups.com<symfony-devs%[email protected]> > For more options, visit this group at > http://groups.google.com/**group/symfony-devs?hl=en<http://groups.google.com/group/symfony-devs?hl=en> > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
