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:
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-... 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, thank you for sharing the proposal of the new realease process and
for making it debatable.
In my opinion, the proposed changes are great and they will improve the
quality of Symfony and its ecosystem.
The only drawback I see is the new set of pull request rules. I think that
sticking to those rules would be awesome ... but a bit unrealistic.
Documenting every change (even if you don't know if it's going to be
accepted), updating changelog and UPGRADE, adding tests for all supported
PHP versions, etc. for every single code change is so cumbersome that most
people don't do it even for their own projects.
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.
> 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:
> 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-...>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
1) for clarification: It looks like the versioning scheme matches the
"Semantic Versioning" model (http://semver.org). Can you explicitly
confirm this? If not, how do you intend to differ?
2) Will there be a roadmap outlining the planned features for releases
conveniently, without having to sort through the issue tracker and
pull requests?
Best regards,
David
On Sep 17, 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.
> 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:
> 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-...
> 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;
> Fabien, thank you for sharing the proposal of the new realease process
> and for making it debatable.
> In my opinion, the proposed changes are great and they will improve the
> quality of Symfony and its ecosystem.
> The only drawback I see is the new set of pull request rules. I think
> that sticking to those rules would be awesome ... but a bit unrealistic.
> Documenting every change (even if you don't know if it's going to be
> accepted), updating changelog and UPGRADE, adding tests for all
> supported PHP versions, etc. for every single code change is so
> cumbersome that most people don't do it even for their own projects.
Oh, I forgot to mention this aspect of things. Of course, we will not ask all pull requests to be merge-ready from the get go. But whenever a PR will be merged (the feature is accepted and the way it is coded is good), then, we must have everything I've described before it can be actually merged and only when it makes sense. When fixing a typo for instance, the PR itself is enough of course.
> On Mon, Sep 17, 2012 at 7:01 AM, Fabien Potencier
> <fabien.potenc...@symfony-project.com
> <mailto: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.
> 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:
> 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.
Like Javier said, one of the problems that I see would be people needing to make the changes for the documentation/upgrade files even if their PR might not be accepted in the end.
Maybe having some sort of two steps process where first a PR is accepted for merge then the rest of the things are done to statisfy the checklist are done would help people in this process. This way even if the author of the PR becomes unavailable someone else could do the rest of the things if the PR is really good and should be merged asap :)
Also a roadmap of features would be very helpful. Think for example the caching component/bundle which is now missing from the framework entierly, or support for UTF-8 routes and so on. Instead of having all people asking for all sorts of features, having a central place where they could check the future featutes/changes and have a way to either submit ideas or comments for a certain feature would definately go a long way.
On Monday, September 17, 2012 8:01:18 AM UTC+3, Fabien Potencier 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.
> 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:
> 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-... > list. But I've
> 1) for clarification: It looks like the versioning scheme matches the
> "Semantic Versioning" model (http://semver.org). Can you explicitly
> confirm this? If not, how do you intend to differ?
Yes, I confirm. And by the way, we have been using this versioning scheme since 2005. Nothing new here.
> 2) Will there be a roadmap outlining the planned features for releases
> conveniently, without having to sort through the issue tracker and
> pull requests?
I'm not sure about this one. Symfony grows organically, because people want to solve problems. So, all the new features come from developers. We do not plan in advance, except for postponed features, or features asked in the tracker without an implementation, or big features that take more than one iteration to finish... which is probably enough.
> On Sep 17, 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.
>> 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:
>> 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
I think that what you suggest is a very good plan. If no one comes up
with a better solutions it should be put into practice.
Do you have any thoughts about new major PHP releases? Current minimum
PHP version is 5.3.3. PHP 5.4 is not adapted by enterprise systems yet
- but it is only a matter of time.
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.
> 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.
> 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-... 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.
On Sep 17, 2012, at 8:59 AM, Fabien Potencier <fabien.potenc...@symfony-project.com> wrote:
>> 2) Will there be a roadmap outlining the planned features for releases
>> conveniently, without having to sort through the issue tracker and
>> pull requests?
> I'm not sure about this one. Symfony grows organically, because people want to solve problems. So, all the new features come from developers. We do not plan in advance, except for postponed features, or features asked in the tracker without an implementation, or big features that take more than one iteration to finish... which is probably enough.
I think we should have a few high profile features picked out. I also think we should have someone assigned to help coordinate things. Their job is to also keep a close eye on features that were merged but end up requiring further PRs to stabilize to ensure that if we do need to revert something, we do it in time etc. Their job to some extend would also be to ensure that if a PR that provides a feature we wanted in gets stuck to try and see if he can get some resources in the community. This is kind of the job of a release manager inside PHP (though RMs in PHP usually also have more technical tasks, which I dont think we need for Symfony).
I have one little question concerning non LTS releases:
On Monday, September 17, 2012 7:01:18 AM UTC+2, Fabien Potencier wrote: > 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).
Is this 8 months after the initial release of a non LTS release or 8 months after the subsequent release?
In case of the first alternative that would mean that we'd have to upgrade to the next release within two months, which is quite a short time regarding application release cycles in some environments (and a general hesitation to jump on x.y.0 releases ... ).
> Do you have any thoughts about new major PHP releases? Current minimum
> PHP version is 5.3.3. PHP 5.4 is not adapted by enterprise systems yet
> - but it is only a matter of time.
i guess 5.3 will stay around for quite a while. not all hosters are
quick to update.
making real use of 5.4 means breaking backwards compatibility in a very
fundamental way.
i think php > 5.3 is a discussion for symfony 3, not for any 2.x version.
cheers,david
ps: +1 for fabiens proposal from me.
-- Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
> I have one little question concerning non LTS releases:
> On Monday, September 17, 2012 7:01:18 AM UTC+2, Fabien Potencier wrote:
> 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).
> Is this 8 months after the initial release of a non LTS release or 8
> months after the subsequent release?
> In case of the first alternative that would mean that we'd have to
> upgrade to the next release within two months, which is quite a short
> time regarding application release cycles in some environments (and a
> general hesitation to jump on x.y.0 releases ... ).
Yes, you have 2 months to upgrade. But this is really your choice: if you cannot be fast, just use the LTS releases.
This is already quite an improvement over the current situation, where you had no overlap between releases (talking about symfony1 here).
> --
> 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+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
I personally (from experience) have found that features blocking a release
can end in disaster and can upset the whole principal of a time-based
release model as the feature can end up delaying the release; especially if
it’s a feature that many want but not many want to help with.
As for > 5.3, at the moment 5.2 is the most used PHP version; followed
closely by 5.3. However the amount of users/hosts using 5.4 is currently
quite small and isn't worth thinking about until at least 2.7 or 3.0 (2015
or later). The fact that 5.3 was first released in 2009 and the fact that it
still is not as used as 5.2 (2006) is shocking.
I think having to complete the whole checklist done for something straight
away for something that might not be used might put off new contributors. As
has been suggested a 2-step PR process where after it is mostly done; if it
looks like it will be merged then complete the checklist (documentation
etc.) rather than straight away. This also means that if the developer is
asked to change anything significant this can be done before documentation
etc. is written and it therefore means that does not also need updating.
+1 to the proposal generally though. It seems like a great way to go.
Thanks
Michael Cullum
> -----Original Message-----
> From: symfony-devs@googlegroups.com [mailto:symfony-
> devs@googlegroups.com] On Behalf Of Fabien Potencier
> Sent: 17 September 2012 06:01
> To: symfony-devs@googlegroups.com
> Subject: [symfony-devs] A formal release process proposal
> 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
> 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
> I personally (from experience) have found that features blocking a > release can end in disaster and can upset the whole principal of a > time-based release model as the feature can end up delaying the > release; especially if it's a feature that many want but not many want > to help with.
> As for > 5.3, at the moment 5.2 is the most used PHP version; followed > closely by 5.3. However the amount of users/hosts using 5.4 is > currently quite small and isn't worth thinking about until at least > 2.7 or 3.0 (2015 or later). The fact that 5.3 was first released in > 2009 and the fact that it still is not as used as 5.2 (2006) is shocking.
> I think having to complete the whole checklist done for something > straight away for something that might not be used might put off new > contributors. As has been suggested a 2-step PR process where after it > is mostly done; if it looks like it will be merged then complete the > checklist (documentation etc.) rather than straight away. This also > means that if the developer is asked to change anything significant > this can be done before documentation etc. is written and it therefore > means that does not also need updating.
Merging the PR before the documentation PR is done is a bad idea IMO. It will lead to the same issue than currently: no doc PR done in many cases.
However, as Fabien said in a previous mail, having the full checklist is not required to open the PR. It would be required to merge it, meaning you can start writing the doc once the code review has validated the way it is done.
> Yaml component is also used by many third-party code, i think it will > be good to place it with the low level components;
> I also find the idea of Lukas Smith is good, release manager profile :)
> finally, is there is a plane for translating the documentation ?
There is already some work on translations. And the official website already displays the Italian translation (since several months) and the French one (since a few weeks).
Other translations are also in progress but are not yet completed and so not rendered on the official site (outdated or incomplete translations are worse than no translation). You can have more informations in the doc: http://symfony.com/doc/current/contributing/documentation/translation...
@stof it's true that most of the current PR don't provide the documentation for it but on the other hand having a two-step good-to-merge process would ease up the problems with it.
First and foremost the PR should reach a state as close to final as possible in terms of features and code then it should be flagged as good for merge (or something that reflects the state better).
Then the PR should cover all the other aspects before needing to be merged like CS and documentation, or anything else that's decided to be done in this step. When the second step is done the PR should be changed to ready for merge and be merged as soon as possible.
This should be done for every type of PR, feature addition, feature change and bug fix. This way if for example one does the code for the PR but becomes unavailable then someone else could pickup the documentation/CS for it and do it so that the PR can be merged. I believe that people that would want a certain PR to be merged would then be motived to finish the reminder of the process for a PR to be accepted if the need occurs.
Also, if we'd have a roadmap with the changes planned for each release that could be interactive, vote for a certain feature to be done faster that the other and so on then people would know when to expect a certain thing to become available. For example see the way YouTrack from JetBrains allows it, see http://youtrack.jetbrains.com/issues/WI for PhpStorm/WI as an example (but not as yet another issue tracker), which I believe it's a very good way to keep track of what users want merged/implemented faster.
I know that Symfony is based on a community of contributors, it's a different model from JetBrains' one, so maybe voting for features wouldn't seem so obvious but in the long run contributors would be able to channel their efforts better imo.
Also validating the CS on the second step would allow one to focus on doing the functionality first then fix any quirks remaining in the code would ease up the review process of the PR, where possible.
And a well defined checklist for a PR to cover would also help keeping track of things fresh contributors need to handle to know that their PR can be merged or not.
On Monday, September 17, 2012 6:57:28 PM UTC+3, Christophe COEVOET wrote:
> Le 17/09/2012 17:51, Michael C a écrit :
> I personally (from experience) have found that features blocking a > release can end in disaster and can upset the whole principal of a > time-based release model as the feature can end up delaying the release; > especially if it’s a feature that many want but not many want to help with.
> As for > 5.3, at the moment 5.2 is the most used PHP version; followed > closely by 5.3. However the amount of users/hosts using 5.4 is currently > quite small and isn't worth thinking about until at least 2.7 or 3.0 (2015 > or later). The fact that 5.3 was first released in 2009 and the fact that > it still is not as used as 5.2 (2006) is shocking.
> I think having to complete the whole checklist done for something straight > away for something that might not be used might put off new contributors. > As has been suggested a 2-step PR process where after it is mostly done; if > it looks like it will be merged then complete the checklist (documentation > etc.) rather than straight away. This also means that if the developer is > asked to change anything significant this can be done before documentation > etc. is written and it therefore means that does not also need updating.
> Merging the PR before the documentation PR is done is a bad idea IMO. It > will lead to the same issue than currently: no doc PR done in many cases.
> However, as Fabien said in a previous mail, having the full checklist is > not required to open the PR. It would be required to merge it, meaning you > can start writing the doc once the code review has validated the way it is > done.
> 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:
> 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-...>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
The release approach seems indeed good way to move forward. However if
you would want to have symfony2 being used in a more enterprise enviroment
I'm afraid that 3 years of LTS isn't enough. Especially because they are
not always in the driving seat to keep up with releases. I know that for
most web projects 3 years a long time, but it isn't in the enterprise
world. Especially if already takes sometimes one year to deliver a project.
On Mon, Sep 17, 2012 at 8:41 AM, Javier Eguiluz <javier.egui...@gmail.com>wrote:
> Fabien, thank you for sharing the proposal of the new realease process and
> for making it debatable.
> In my opinion, the proposed changes are great and they will improve the
> quality of Symfony and its ecosystem.
> The only drawback I see is the new set of pull request rules. I think that
> sticking to those rules would be awesome ... but a bit unrealistic.
> Documenting every change (even if you don't know if it's going to be
> accepted), updating changelog and UPGRADE, adding tests for all supported
> PHP versions, etc. for every single code change is so cumbersome that most
> people don't do it even for their own projects.
> On Mon, 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.
>> 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:
>> 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
> The release approach seems indeed good way to move forward. However if you
> would want to have symfony2 being used in a more enterprise enviroment I'm
> afraid that 3 years of LTS isn't enough. Especially because they are not
> always in the driving seat to keep up with releases. I know that for most
> web projects 3 years a long time, but it isn't in the enterprise world.
> Especially if already takes sometimes one year to deliver a project.
It's true. Enterprise is a specific world.
Do you think that there is a demand for a distribution with longer time support?
> On Mon, Sep 17, 2012 at 8:41 AM, Javier Eguiluz <javier.egui...@gmail.com>
> wrote:
>> Fabien, thank you for sharing the proposal of the new realease process and
>> for making it debatable.
>> In my opinion, the proposed changes are great and they will improve the
>> quality of Symfony and its ecosystem.
>> The only drawback I see is the new set of pull request rules. I think that
>> sticking to those rules would be awesome ... but a bit unrealistic.
>> Documenting every change (even if you don't know if it's going to be
>> accepted), updating changelog and UPGRADE, adding tests for all supported
>> PHP versions, etc. for every single code change is so cumbersome that most
>> people don't do it even for their own projects.
>> On Mon, 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.
>>> 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:
>>> 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
> 2012/9/17 Daniel Kucharski <inspi...@gmail.com>:
>> Hey Fabien,
>> The release approach seems indeed good way to move forward. However if you
>> would want to have symfony2 being used in a more enterprise enviroment I'm
>> afraid that 3 years of LTS isn't enough. Especially because they are not
>> always in the driving seat to keep up with releases. I know that for most
>> web projects 3 years a long time, but it isn't in the enterprise world.
>> Especially if already takes sometimes one year to deliver a project.
> It's true. Enterprise is a specific world.
> Do you think that there is a demand for a distribution with longer time support?
>> On Mon, Sep 17, 2012 at 8:41 AM, Javier Eguiluz <javier.egui...@gmail.com>
>> wrote:
>>> Fabien, thank you for sharing the proposal of the new realease process and
>>> for making it debatable.
>>> In my opinion, the proposed changes are great and they will improve the
>>> quality of Symfony and its ecosystem.
>>> The only drawback I see is the new set of pull request rules. I think that
>>> sticking to those rules would be awesome ... but a bit unrealistic.
>>> Documenting every change (even if you don't know if it's going to be
>>> accepted), updating changelog and UPGRADE, adding tests for all supported
>>> PHP versions, etc. for every single code change is so cumbersome that most
>>> people don't do it even for their own projects.
>>> On Mon, 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.
>>>> 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:
>>>> 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.
On Monday, September 17, 2012 9:49:26 PM UTC+4, Florin Patan wrote:
> @stof it's true that most of the current PR don't provide the > documentation for it but on the other hand having a two-step good-to-merge > process would ease up the problems with it.
> First and foremost the PR should reach a state as close to final as > possible in terms of features and code then it should be flagged as good > for merge (or something that reflects the state better).
> Then the PR should cover all the other aspects before needing to be merged > like CS and documentation, or anything else that's decided to be done in > this step. When the second step is done the PR should be changed to ready > for merge and be merged as soon as possible.
> This should be done for every type of PR, feature addition, feature change > and bug fix. This way if for example one does the code for the PR but > becomes unavailable then someone else could pickup the documentation/CS for > it and do it so that the PR can be merged. I believe that people that would > want a certain PR to be merged would then be motived to finish the reminder > of the process for a PR to be accepted if the need occurs.
> Also, if we'd have a roadmap with the changes planned for each release > that could be interactive, vote for a certain feature to be done faster > that the other and so on then people would know when to expect a certain > thing to become available. For example see the way YouTrack from JetBrains > allows it, see http://youtrack.jetbrains.com/issues/WI for PhpStorm/WI as > an example (but not as yet another issue tracker), which I believe it's a > very good way to keep track of what users want merged/implemented faster.
> I know that Symfony is based on a community of contributors, it's a > different model from JetBrains' one, so maybe voting for features wouldn't > seem so obvious but in the long run contributors would be able to channel > their efforts better imo.
> Also validating the CS on the second step would allow one to focus on > doing the functionality first then fix any quirks remaining in the code > would ease up the review process of the PR, where possible.
> And a well defined checklist for a PR to cover would also help keeping > track of things fresh contributors need to handle to know that their PR can > be merged or not.
> --
> Florin
> On Monday, September 17, 2012 6:57:28 PM UTC+3, Christophe COEVOET wrote:
>> Le 17/09/2012 17:51, Michael C a écrit :
>> I personally (from experience) have found that features blocking a >> release can end in disaster and can upset the whole principal of a >> time-based release model as the feature can end up delaying the release; >> especially if it’s a feature that many want but not many want to help with.
>> As for > 5.3, at the moment 5.2 is the most used PHP version; followed >> closely by 5.3. However the amount of users/hosts using 5.4 is currently >> quite small and isn't worth thinking about until at least 2.7 or 3.0 (2015 >> or later). The fact that 5.3 was first released in 2009 and the fact that >> it still is not as used as 5.2 (2006) is shocking.
>> I think having to complete the whole checklist done for something >> straight away for something that might not be used might put off new >> contributors. As has been suggested a 2-step PR process where after it is >> mostly done; if it looks like it will be merged then complete the checklist >> (documentation etc.) rather than straight away. This also means that if the >> developer is asked to change anything significant this can be done before >> documentation etc. is written and it therefore means that does not also >> need updating.
>> Merging the PR before the documentation PR is done is a bad idea IMO. >> It will lead to the same issue than currently: no doc PR done in many cases.
>> However, as Fabien said in a previous mail, having the full checklist is >> not required to open the PR. It would be required to merge it, meaning you >> can start writing the doc once the code review has validated the way it is >> done.
> Merging the PR before the documentation PR is done is a bad idea IMO. It
> will lead to the same issue than currently: no doc PR done in many cases.
> However, as Fabien said in a previous mail, having the full checklist is
> not required to open the PR. It would be required to merge it, meaning
> you can start writing the doc once the code review has validated the way
> it is done.
> --
> Christophe | Stof
This is actually one of the reasons why Drupal's inline Docblocks are so much more extensive than Symfony's. We rely on the docblocks for much of our developer-facing documentation. That means there's no separate patch/PR for documentation about a system, at least at the code level. If the documentation isn't "ready", it's obvious from the PR itself.
Architectural-level documentation is a separate matter and that can't really be merged into the code base sanely, but having more of the documentation in the code itself makes it easier to enforce adding code changes and matching documentation at the same time.
>> * 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.
Related logistical note: Drupal 8 is currently looking at code freeze 1 April next year. However, I think it's a fair bet that we'll want to ship on 2.3 LTS, not on 2.2, which would go out of support well-before Drupal 8 does. We'll need to coordinate between Fabien (and whoever else is relevant) on the Symfony side and Dries/catch (the Drupal 8 leads) on the Drupal side to see how we want to handle that. Since we'll likely be chasing master until then we may be able to just make an exception to our code freeze for Symfony 2.3.
No action needed right now; I'm just flagging it as a discussion point. I'll try looping in the Drupalers on my side. I cannot speak for the release schedule of other Symfony-using projects.
<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.
> 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:
> 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-... 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.
> --
> 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
