In principle, this sounds like a good plan. It will increase the burden on bundle developers though, and this is probably something which can communicated better in the future as other have pointed out already.
I'm wondering however which PRs are reverted. All PRs that break BC, or just the ones that break BC and add a feature, or also the ones that break BC and fix a bug? If we revert bug fixing, BC breaking PRs, then obviously 2.1 will ship with more non-fixable bugs. If we do not revert these bug-fixing BC breaking PRs, then there are BC breaks for 2.1 and 2.2. Both options do not sound ideal to me, but I have no clear view of which PRs we are talking about. Considering that Fabien said he would like to release 2.2 in July/August, do we really need to make a 2.1 release in June? I know it's Symfony Live there, and it would be cool to have, but we also delayed the Symfony2 final release after last years Symfony conference. To me, it does not really matter, but it seems like another viable option to consider. Cheers, Johannes On Fri, Apr 27, 2012 at 7:17 AM, Lukas Kahwe Smith <[email protected]>wrote: > On 27.04.2012, at 13:35, Thomas Lundquist <[email protected]> > wrote: > > > On Fri, Apr 27, 2012 at 12:22:47PM +0200, Christophe COEVOET wrote: > > > >> If we keep the current code > >> for 2.1, it will be breaking BC twice as the current Form code is > >> not totally mature and needs some more changes (look at bernhard's > >> pending pull requests). If you want to do all breaks for 2.1, it > >> means delaying the release, which is exactly was we are trying to > >> avoid. > > > > It is *a lot* better to wait until ready and so all BC breaks in > > one go rather than breaking BC between every minor release. > > you make it sound like BC breaks are binary. there is a difference in the > scope of BC breaks. some affect pretty much all users (f.e. the > security_factories.xml change), others might affect very few that were > messing in the guts of the framework. > > now we did clearly define which components are to be considered stable in > terms of API and which are not. it was clear at that point that this isnt > ideal but we decided there was enough in Symfony2 worth release that we did. > > furthermore overall i must say i am quite impressed with how well Bundles > are being maintained to work with both 2.0 and 2.1. i also think that > thanks to github the situation will never become as bad was they were in > symfony 1.x. furthermore back then we were really doing major refactorings > in the guts of the framework changing very fundamental things. this is not > the case in Symfony2. > > in summary: yes its not ideal but it simply is aresult of the resources we > have available. > > > Then you can explain, document and prepare users and developers > > for this. They will understand. > > > > And which one is planned to be an LTS? 2.1 with broken forms or 2.2 > > which will be out "some time"? > > its not clear yet which release will be the LTS and when that release will > come. its certain it will not be 2.1 > > regards, > Lukas > > -- > 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
