Received: by 10.50.222.132 with SMTP id qm4mr2783215igc.2.1347943749832; Mon, 17 Sep 2012 21:49:09 -0700 (PDT) X-BeenThere: symfony-devs@googlegroups.com Received: by 10.50.160.202 with SMTP id xm10ls6625600igb.3.gmail; Mon, 17 Sep 2012 21:49:07 -0700 (PDT) Received: by 10.50.149.228 with SMTP id ud4mr4654128igb.0.1347943747621; Mon, 17 Sep 2012 21:49:07 -0700 (PDT) Received: by 10.50.57.75 with SMTP id g11msigq; Sun, 16 Sep 2012 23:57:30 -0700 (PDT) Received: by 10.50.153.226 with SMTP id vj2mr969361igb.3.1347865050273; Sun, 16 Sep 2012 23:57:30 -0700 (PDT) Received: by 10.50.153.226 with SMTP id vj2mr969360igb.3.1347865050244; Sun, 16 Sep 2012 23:57:30 -0700 (PDT) Return-Path: Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by gmr-mx.google.com with ESMTPS id mb9si1672186igc.1.2012.09.16.23.57.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Sep 2012 23:57:30 -0700 (PDT) Received-SPF: pass (google.com: domain of inspi...@gmail.com designates 209.85.223.182 as permitted sender) client-ip=209.85.223.182; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of inspi...@gmail.com designates 209.85.223.182 as permitted sender) smtp.mail=inspi...@gmail.com; dkim=pass header...@gmail.com Received: by mail-ie0-f182.google.com with SMTP id 17so8512037iea.27 for ; Sun, 16 Sep 2012 23:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gLuhz5feAJPqOvjGMAGz2AtmesisRif2ETARFVcK4Vk=; b=gieWu2Ol/d2eo4e1icidfTjulUhG5j9yQRjqXban7yNRVvQ26DNPwt4M9di2sYe2kx CVCSAFoQOs5I4cD+nvaztMxne3dgrPxQm9kxiBcGFD3sres9Yf33B+hv5sEssaPOPalQ BcdxIy0MdCe81yDwPeac/N/kuZLRa0AxCw2K2XOJ+eY0cEskDo53VoAI8emvnCGjz0Qi wJL3I80pBESToqCeKkpxkh08jUZPm/IIa+V1RBxnEViAm2tpdVS6zGLma0AqNjr2FW56 HAx7eRbAYs4VreUzCN6g/rM16WE9EAEElwBtvG91+seVRK9Q0oF9J8gSgpOrKY0IRvpN 5J9Q== MIME-Version: 1.0 Received: by 10.50.7.210 with SMTP id l18mr5709059iga.26.1347865050091; Sun, 16 Sep 2012 23:57:30 -0700 (PDT) Received: by 10.64.20.111 with HTTP; Sun, 16 Sep 2012 23:57:30 -0700 (PDT) In-Reply-To: References: <5056AE99.9050...@symfony.com> Date: Mon, 17 Sep 2012 08:57:30 +0200 Message-ID: Subject: Re: [symfony-devs] A formal release process proposal From: Daniel Kucharski To: symfony-devs@googlegroups.com Content-Type: multipart/alternative; boundary=f46d04462e60840ffd04c9e049f9 --f46d04462e60840ffd04c9e049f9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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= . On Mon, Sep 17, 2012 at 8:41 AM, Javier Eguiluz w= rote: > Fabien, thank you for sharing the proposal of the new realease process an= d > 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 tha= t > 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 mos= t > people don't do it even for their own projects. > > -- > Javier Eguiluz > www.symfony.es > > 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 oft= en >> without a clear roadmap is quite difficult. Adopting a more formal relea= se >> 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 lea= st, >> 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 th= e >> 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 (witho= ut >> 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 a= n >> 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 th= e >> scope of Twig is also smaller). >> >> Six month releases mean that two releases fit in a year and so, everybod= y >> 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 e= ach >> 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 backw= ard >> compatibility depends on the component we are talking about. The followi= ng >> 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 one= s; >> >> * Stabilisation: 2 months to fix bugs, prepare the release, and wait fo= r >> 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, an= d >> 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 tha= t >> 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 schedul= ed >> for Symfony 3.0. And the work on 3.0 will start whenever we think that w= e >> 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 t= o >> 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 feat= ure >> 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 [heade= r]( >> http://symfony.com/**doc/current/contributing/code/** >> patches.html#make-a-pull-**request)/checklist. But I've d= one 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 e= ven >> 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 al= l >> the tests pass on all supported PHP versions; >> >> * The documentation has been updated (with a pending pull request on >> symfony/symfony-docs); >> >> * The changelog and upgrade files have been updated; >> >> * No backward compatibility break has been introduced; >> >> * If it is a fix, it has been applied to the oldest and still supported >> Symfony version; >> >> * For major features, a RFC has been written, discussed, and approved. >> >> As I said at the beginning, this is a draft, and you are all welcome to >> chime in and propose changes. >> >> >> -- >> Fabien Potencier >> Sensio CEO - Symfony lead developer >> sensiolabs.com | symfony.com | fabien.potencier.org >> T=E9l: +33 1 40 99 80 80 >> >> -- >> If you want to report a vulnerability issue on symfony, please send it t= o >> 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=3Den >> > > -- > 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=3Den > --f46d04462e60840ffd04c9e049f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hey Fabien,
=A0
The release=A0approach seems indeed good way to move forward.=A0=A0 Ho= wever if you=A0would want to have symfony2 being used in=A0a more enterpris= e enviroment I'm afraid that=A03 years of LTS isn't enough.=A0=A0Es= pecially=A0because they are not always in the driving seat to=A0keep up wit= h releases.=A0=A0 I know that for most web projects 3 years a long time, bu= t it isn't in the enterprise world.=A0 Especially if already takes some= times one year to deliver a project.
=A0
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 th= e 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. Do= cumenting every change (even if you don't know if it's going to be = accepted), updating changelog and UPGRADE, adding tests for all supported P= HP versions, etc. for every single code change is so cumbersome that most p= eople don't do it even for their own projects.

--
Javier Eguiluz

On Mon, Sep 17, 2012 at 7:01 AM, Fabien Potencie= r <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 talke= d about adopting a shorter release cycle for Symfony for quite some time no= w, and I think that this is the right time to discuss it.

As we have all noticed, Symfony enjoys a large community of "core&= quot; developers: a core developer being someone who contribute to Symfony = on a regular basis. The flow of pull requests has been outstanding and stea= dy for the past two years, and with such an activity, trying to release oft= en without a clear roadmap is quite difficult. Adopting a more formal relea= se cycle will also give more visibility to the contributors and allow for e= veryone 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 t= o apply the new release process as soon as possible and if possible for Sym= fony 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/sym= fony repository, but of course, I hope that third-party code related to Sym= fony (like the Symfony bundles) will also adopt it (at least, just for the = timeline).

Let's list the goals for the new process:

=A0* Shorten the r= elease cycle;

=A0* Keep backward compatibility as much as possible;<= br>
=A0* Enhance the overall quality of the framework (not just the code= , but documentation, bundles, ...);

=A0* Give more visibility to our "customers": developers usin= g the framework to get their job done and Open-Soure projects using/embeddi= ng Symfony;

=A0* Improve the experience of Symfony core contributors= by controlling the flow of incoming pull requests (why pull requests are n= ot always merged right away? when will a new feature be merged? when breaki= ng BC is acceptable? ...);

=A0* Coordinate our timeline with projects that we are using (Doctrine,= Propel, Monolog, Assetic, Twig, ...) but also with projects that are using= /embedding Symfony;

=A0* Give time to the Symfony ecosystem to catch= up with the new versions (bundleauthors, documentation writers, translator= s, ...);
=A0* Allow developers to benefit from the new features faster.

That&= #39;s a lot to take care of!

So, without further ado, here is my pla= n.

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 no= n-ready features to be postponed to the next version (without having to wai= t 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 t= ime to learn and upgrade. The way to make everyone happy is to ensure an ea= sy 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 si= nce 1.0; that's very fast and it has been possible because we've ke= pt backward compatibility between all major releases (and of course the sco= pe of Twig is also smaller).

Six month releases mean that two releases fit in a year and so, everybo= dy 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 eac= h 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 backwar= d compatibility depends on the component we are talking about. The followin= g components must never break backward compatibility because they are the l= ow-level architecture of the framework and also because so many people rely= on them:

=A0* ClassLoader
=A0* Console
=A0* DependencyInjection
=A0* Ev= entDispatcher
=A0* HttpFoundation
=A0* HttpKernel
=A0* Routing
=
Backward compatibility should be easy to keep for the following compone= nts:

=A0* BrowserKit
=A0* CssSelector
=A0* DomCrawler
=A0* Filesystem=A0* Finder
=A0* Locale
=A0* OptionsResolver
=A0* Process
=A0= * Templating
=A0* Yaml

And these components should probably becom= e more stable soon, but that's not that easy (yet):

=A0* Config
=A0* Form
=A0* Security
=A0* Serializer
=A0* Tr= anslation
=A0* 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 h= elp, but also because the six month period itself should be cut in shorter = periods:

=A0* Development: 4 months to add new features and to enhance existing = ones;

=A0* Stabilisation: 2 months to fix bugs, prepare the release,= and wait for the whole ecosystem to catch up.

During the developmen= t phase, we can revert any new feature if we think that we won't be abl= e 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 c= an 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 p= ast, the first LTS should be Symfony 2.3.

Each LTS release will be s= upported for a 3 year period but it will also be supported for at least a y= ear after the next LTS is released. So, it means that we are going to relea= se a new LTS version every two years.

This dual release cycle should make everyone happy. If you are a fast m= over, you want to work with the latest and the greatest, stick with the sta= ndard support releases: you have a new version every six months, and you ha= ve 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 s= chedule for the next few versions:

=A0* Symfony 2.2 will be released= at the end of February 2013;

=A0* 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 mont= hs for releases);

=A0* Symfony 2.4 will be released at the end of November 2013;

= =A0* Symfony 2.5 will be released at the end of Mai 2014;

=A0* ...
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: th= is is our last chance to break backward compatibility.

Symfony 3.0
-----------

After the release of Symfony 2.3, bac= kward compatibility will be kept at all cost. If it is not possible, the fe= ature/enhancement will be scheduled for Symfony 3.0. And the work on 3.0 wi= ll start whenever we think that we have enough great features under our bel= t to make it worth it.

Maintenance
-----------

After Symfony 2.3, non LTS releases w= ill be maintained for 8 months to give people plenty of time to upgrade (ke= ep 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 wel= l (no BC and a fixed schedule), we need to formalise the contribution proce= ss a bit more. Every new Symfony feature or enhancement must be worked on v= ia Git pull requests. A few months ago, we formalised the pull request proc= ess a bit by adding a required [header](http://symfony.com/doc/current/contributing/code/pat= ches.html#make-a-pull-request)/check list. But I've done a p= oor 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:
<= br>=A0* The code is correct and it uses the Symfony way of doing things (na= ming conventions, coding standards, ...);

=A0* The new code is teste= d (or the bug to fix is covered by tests) and all the tests pass on all sup= ported PHP versions;

=A0* The documentation has been updated (with a pending pull request on= symfony/symfony-docs);

=A0* The changelog and upgrade files have be= en updated;

=A0* No backward compatibility break has been introduced= ;

=A0* If it is a fix, it has been applied to the oldest and still suppor= ted Symfony version;

=A0* For major features, a RFC has been written= , discussed, and approved.

As I said at the beginning, this is a dra= ft, and you are all welcome to chime in and propose changes.


--
Fabien Potencier
Sensio CEO - Symfony lead developer
<= a href=3D"http://sensiolabs.com/" target=3D"_blank">sensiolabs.com | symfony.com | fabien.potencier.org
T=E9l: +33 1 40 99 80 80

--
If you want to repor= t a vulnerability issue on symfony, please send it to security at symfony-project.com<= br>
You received this message because you are subscribed to the Google
G= roups "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+unsubsc= ribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=3Den

--
If you want to report a vulnerability issue on symfony, pleas= e send it to security at symfony-project.com
=A0
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, vi= sit this group at
http://groups.google.com/group/symfony-devs?hl= =3Den

--f46d04462e60840ffd04c9e049f9--