2012/9/18 Michał Piotrowski <mkkp...@gmail.com>: > Hi, > > 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?
I mean paid distribution with paid 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. >>> >>> -- >>> 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 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 >>>> list. But I've done a poor job in enforcing the rule. So, I'm going to be >>>> uncompromising about it now and at the same time I'd like to introduce even >>>> more checks in the list. >>>> >>>> A pull request will only be merged if the following rules are met: >>>> >>>> * The code is correct and it uses the Symfony way of doing things >>>> (naming conventions, coding standards, ...); >>>> >>>> * The new code is tested (or the bug to fix is covered by tests) and all >>>> the tests pass on all supported PHP versions; >>>> >>>> * The documentation has been updated (with a pending pull request on >>>> symfony/symfony-docs); >>>> >>>> * The changelog and upgrade files have been updated; >>>> >>>> * No backward compatibility break has been introduced; >>>> >>>> * If it is a fix, it has been applied to the oldest and still supported >>>> Symfony version; >>>> >>>> * For major features, a RFC has been written, discussed, and approved. >>>> >>>> As I said at the beginning, this is a draft, and you are all welcome to >>>> chime in and propose changes. >>>> >>>> >>>> -- >>>> Fabien Potencier >>>> Sensio CEO - Symfony lead developer >>>> sensiolabs.com | symfony.com | fabien.potencier.org >>>> Tél: +33 1 40 99 80 80 >>>> >>>> -- >>>> If you want to report a vulnerability issue on symfony, please send it to >>>> security at symfony-project.com >>>> >>>> You received this message because you are subscribed to the Google >>>> Groups "symfony developers" group. >>>> To post to this group, send email to 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 >> >> >> -- >> 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 > > > > -- > Best regards, > Michal > > http://eventhorizon.pl/ > https://getactive.pl/ -- Best regards, Michal http://eventhorizon.pl/ https://getactive.pl/ -- 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
