On Sep 17, 2012, at 7:01 AM, Fabien Potencier <fabien.potenc...@symfony-project.com> wrote:
> 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. As you point out, this is infact more or less what we have agreed upon during meetings before we went to 2.0. We just failed to execute on that, probably also because we never formally wrote it down. > * Give more visibility to our "customers": developers using the framework to > get their job done and Open-Soure projects using/embedding Symfony; > .. > * Coordinate our timeline with projects that we are using (Doctrine, Propel, > Monolog, Assetic, Twig, ...) but also with projects that are using/embedding > Symfony; I think this is a very important point. This way we do not need to do complex coordinations with releases, because the general timeframe (maybe +- 3 weeks) is very clear. However we will also need to setup some coordination for point releases (especially security stuff), but also general bug fixing. However that is beyond of the scope of this proposal. > Timeline > -------- > 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). Just to expand on why this makes sense to me also: If you want to get a feature into Symfony2, you can either get it into the next release which should be less than 6 months away .. or if its too late in the release cycle (which means its likely less than 3 months to the next release and its a big complex feature), then you just have to wait less than 9 months to get it into the release after that. So as a result nothing has really changed in how fast you can get a feature in. The difference is that you can very quickly know the point in time when the feature will make it in. > 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. I would actually prefer April, October. May seems too close to the summer and November too close to the "lets get some last features done on this years budget". Then again one could say such a feature is the upgrade to the latest version. > 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. We should survey our user base of large projects if 3 years is sufficiently long for them. Which brings me back to the point of needing some way to coordinate stuff with them. > 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. sounds good to me .. though like I said I would prefer us to start in April. > 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. Yes, we should tag such things clearly in the ticket system. > 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). Hmm I wonder if we should make it possible for people to skip one non LTS release. > 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 > 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. this sounds like a good idea, but for that we need to work on a better work process. Right now all the work for most PRs sit with one person. If we expect that one person to do all of the above, I think we will end up in a situation where people wait for others to do the PR even if the idea has been laid out in a ticket or the mailinglist, or PRs sit open for a long time. I have said this before on the list: Its possible to send PRs to the repo on which a PR is based. Also its possible to create a new PR based on the repo from which the original PR is based. So please use this to assist people to finish PRs. In the same way we then also need people to help on the related doc PR. regards, Lukas -- 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 symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
