On 9/17/12 8:41 AM, Javier Eguiluz 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.
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.
Fabien
--
Javier Eguiluz
www.symfony.es <http://www.symfony.es>
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:
* ClassLoader
* Console
* DependencyInjection
* EventDispatcher
* HttpFoundation
* HttpKernel
* Routing
Backward compatibility should be easy to keep for the following
components:
* BrowserKit
* CssSelector
* DomCrawler
* Filesystem
* Finder
* Locale
* OptionsResolver
* Process
* Templating
* Yaml
And these components should probably become more stable soon, but
that's not that easy (yet):
* Config
* Form
* Security
* Serializer
* Translation
* Validator
Six months can be seen as a rather short period to make a new
release, especially if we look at what we did in the past. I think
we can make it work because we have now more people able to help,
but also because the six month period itself should be cut in
shorter periods:
* Development: 4 months to add new features and to enhance
existing ones;
* Stabilisation: 2 months to fix bugs, prepare the release, and
wait for the whole ecosystem to catch up.
During the development phase, we can revert any new feature if we
think that we won't be able to finish it in time or if we think that
it won't be stable enough to be included.
During the stabilisation phase, some developers might still work on
new features for the next version, but it would be better if most
developers can concentrate on finishing the current version.
By the way, when I have a look at the pull requests today, I think
that we already have enough features for Symfony 2.2.
Long Term Support release
-------------------------
We've not yet published our LTS release for Symfony2. As I mentioned
it in the past, the first LTS should be Symfony 2.3.
Each LTS release will be supported for a 3 year period but it will
also be supported for at least a year after the next LTS is
released. So, it means that we are going to release a new LTS
version every two years.
This dual release cycle should make everyone happy. If you are a
fast mover, you want to work with the latest and the greatest, stick
with the standard support releases: you have a new version every six
months, and you have two months to upgrade to the next one. If you
are a big company, and you want more stability, stick with the long
term support releases: you get a new version every two years and you
have a year to upgrade.
Schedule
--------
To make things more concrete, here is the schedule for the next few
versions:
* Symfony 2.2 will be released at the end of February 2013;
* Symfony 2.3 (the first LTS) will be released at the end of Mai
2013 (only 3 months after 2.2 as it will be a "special" release in
the sense that we will mainly remove the 2.0 BC layer and also
because I think that May and November are the best months for releases);
* Symfony 2.4 will be released at the end of November 2013;
* Symfony 2.5 will be released at the end of Mai 2014;
* ...
So, why not releasing Symfony 2.2 earlier as we already have so many
features waiting in the pull request queue? Because of the next
section: this is our last chance to break backward compatibility.
Symfony 3.0
-----------
After the release of Symfony 2.3, backward compatibility will be
kept at all cost. If it is not possible, the feature/enhancement
will be scheduled for Symfony 3.0. And the work on 3.0 will start
whenever we think that we have enough great features under our belt
to make it worth it.
Maintenance
-----------
After Symfony 2.3, non LTS releases will be maintained for 8 months
to give people plenty of time to upgrade (keep in mind that even if
no BC breaks will have occurred, you might need to upgrade your
applications to benefit from the new features and the new best
practices).
Contributions
-------------
To make the new process works well (no BC and a fixed schedule), we
need to formalise the contribution process a bit more. Every new
Symfony feature or enhancement must be worked on via Git pull
requests. A few months ago, we formalised the pull request process a
bit by adding a required
[header](http://symfony.com/__doc/current/contributing/code/__patches.html#make-a-pull-__request)/check
<http://symfony.com/doc/current/contributing/code/patches.html#make-a-pull-request)/check>
list. But I've done a poor job in enforcing the rule. So, I'm going
to be uncompromising about it now and at the same time I'd like to
introduce even more checks in the list.
A pull request will only be merged if the following rules are met:
* The code is correct and it uses the Symfony way of doing things
(naming conventions, coding standards, ...);
* The new code is tested (or the bug to fix is covered by tests)
and all the tests pass on all supported PHP versions;
* The documentation has been updated (with a pending pull request
on symfony/symfony-docs);
* The changelog and upgrade files have been updated;
* No backward compatibility break has been introduced;
* If it is a fix, it has been applied to the oldest and still
supported Symfony version;
* For major features, a RFC has been written, discussed, and approved.
As I said at the beginning, this is a draft, and you are all welcome
to chime in and propose changes.
--
Fabien Potencier
Sensio CEO - Symfony lead developer
sensiolabs.com <http://sensiolabs.com> | symfony.com
<http://symfony.com> | fabien.potencier.org
<http://fabien.potencier.org>
Tél: +33 1 40 99 80 80 <tel:%2B33%201%2040%2099%2080%2080>
--
If you want to report a vulnerability issue on symfony, please send
it to security at symfony-project.com <http://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
<mailto:symfony-devs@googlegroups.com>
To unsubscribe from this group, send email to
symfony-devs+unsubscribe@__googlegroups.com
<mailto:symfony-devs%2bunsubscr...@googlegroups.com>
For more options, visit this group at
http://groups.google.com/__group/symfony-devs?hl=en
<http://groups.google.com/group/symfony-devs?hl=en>
--
If you want to report a vulnerability issue on symfony, please send it
to security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to
symfony-devs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
