> > Without the form component commits it will be very > easy to upgrade from 2.0 to 2.1. If I'm not mistaken, the 2.1 code > base is quite compatible with the 2.0 branch.
Are you sure? There is absolutely no good reason to release a 2.1 version as soon as possible if 2.1 is not fully BC with 2.0. In that case, it could be a nice strategy to kill 2.0. Otherwise, there is no reason to release a version with "broken forms" (up to you to find a better definition). People who are still using 2.0 won't upgrade if they are not able to upgrade safely. By the way, the Pull Request to revert recent changes on the Form component reverts improvements (which is ok to avoid BC breaks) but also fixes! So what? Why would you want to release a 2.1 version now, and not just to wait four months? Marketing strategy? William 2012/4/28 Matt Robinson <[email protected]> > Some (I think) pragmatic possibilities: > > 1. If it's possible to run the 2.0 Form component in 2.1 (less work than > backing out non-BC changes to 2.1, right?), then bundle the new Form > component separately with a longer term view of making the new version the > default. This is like the transition that Symfony 1.x went through from > Propel to Doctrine as default. People still happily use both, and the 2.0 > Form component still needs to be maintained anyway, since 2.0 is a > long-term-stable release. > > 2. If all the other changes are BC, backport them into 2.0 and release > asap. Then the 2.1 release only has the BC-breaks like Forms. We shouldn't > focus too much on what the version number is, it's the compatibility that's > important. > > Long ago, I remember Fabien mentioned that he hoped there'd be multiple > editions of Symfony2, and that the Standard Edition is just one of them. > Perhaps we could resurrect that idea and have a "Standard edition" (with > guaranteed BC) and an "Edge edition" (which doesn't mind breaking BC). > > In a way we already do this by having 2.0 as a long-term-stable release, > but to do it properly it should get stable, backward compatible changes > backported from the development branch. Otherwise it'll become outdated, > and people who want compatibility and stability will have to sacrifice an > ever-increasing amount of features and improvements as 2.1, 2.2 and 2.3 are > released. This also helps to prevent the community drifting apart into two > groups: those who have to use the Stable 2.0 branch, and those who can risk > BC moving on to 2.1, 2.2 etc. > > > On 27 Apr 2012, at 19:09, Fabien Potencier wrote: > > > Hi all, > > > > The Symfony 2.1 release was expected to be published some time ago and > we struggle with it for two main reasons: > > > > * The number of contributions we have every single day. That's great but > it means that it is never a good time to release because of this last > minute great change that we want to merge first; > > > > * The recent BC breaks in the form/validator components. > > > > But basically, we cannot release 2.1 because of the second point. We > need to be sure that we only break BC for forms only once. So, we have two > options: > > > > * Wait for the form component to stabilize (which means that we are > happy with the state of the API and that enough people have played with it > and are happy with the features) > > > > * Release 2.1 as soon as possible (because we already have quite a few > nice enhancements). > > > > I thought that the second option was do-able by forking master and > reverting some PRs related to the form component (the ones that actually > break BC and are not stable yet because of some bugs or regressions -- > surprisingly, we are not talking about many of them). > > > > Many people think the contrary and so, I want to hear everybody's > opinion on this matter. > > > > Let me reiterate the two possibilities here: > > > > * Wait for the form component to stabilize: we can probably schedule 2.1 > for August 2012. In the meantime, we should concentrate on the form > component and delay other big changes that can affect the stability of the > release. > > > > * Release 2.1 as soon as possible. > > > > Whatever we choose, I want to next Symfony 2 releases to have shorter > release cycles (a bit like what I do with Twig); and for that to happen, we > need to keep BC as much as possible so that people can upgrade to new > versions without any fear. > > > > Fabien > > > > -- > > 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 [email protected] > > To unsubscribe from this group, send email to > > [email protected] > > 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
