I agree with Florin, the lack of a TODO and/or a Roadmap can cause problems to contributors interested in working on new features, instead of fixing reported bugs. The symfony-docs also has this problem.
On Sat, Apr 28, 2012 at 6:16 PM, Florin Patan <[email protected]> wrote: > Hi, > > > +1 for Mark's idea as well. > > But, since there are so many BC breaks on master right now I see no reason > why not merging some other long waited features, like subdomains/flexible > hostnames for Routing component and so on, features that will otherwise > introduce BC breaks yet again for 2.2. > > Symfony 2.1 could be called 'The one when we break BC heavily' but it's > the only one rather that go for more heavy BC breaks in 2.2 and so on. > > Granted, faster release cycles would help this in the future, but for now, > I think Symfony2 should include as many BC breaks as possible in 2.1, have > a stabilize/debug period the be released. It will be painful, but if > properly announced, I don't think people would mind. > > I'm currently working on a somewhat large website, with a couple of > million of users and using master with success and the upgrade process from > 2.0.X to master was pretty decent, about 3 days of hard day/night work, but > I don't want to repeat that again for 2.2 and so on. > > Each major Symfony 2.X should include BC breaks to only 2-3 components > tops and if it's a big/widespread usage component (see the Session > subcomponent, Form components and so on) then announce the breaks, announce > a release schedule, give time to the bundle authors to fix their bundles, > and release the version according to the schedule no matter what Right now > people are just confused about when/where/how a new version of Symfony2 > will appear and just staying a date then passing it it's not a way to gain > traction. > > Also, there are two a big thing missing in Symfony2 ecosystem: a clear > TODO list for each of the milestones which, combined with the other big > problem, the fact that people might not know what's the desired way of > having things done is just annoying for contributors. People might not know > how one wants to for things to be done or what needs to be fixed in order > to speed up achieving a milestone and users as well because they don't know > when to expect a certain set of features or version. And with all due > respect for everyones work, the Form/Routing Components are clear examples > of this going the wrong way, the whole framework waiting for a single > person to do something when instead, the community could do it and that > person just review the work/actively steer it in the right way. > > Kind regards, > Florin > > On Wednesday, April 4, 2012 8:52:37 AM UTC+3, Fabien Potencier wrote: >> >> On 4/4/12 12:53 AM, Lukas Kahwe Smith wrote: >> > Aloha, >> > >> > since my last mail on this topic kinda went without a reply. >> > >> > can we start talking about a timeline for 2.1? >> >> Thanks for bringing this topic on the table again. We should definitely >> start working on the 2.1 plan. >> >> > 1) i believe that we still need to really review all BC breaks, >> especially the form related ones, and determine if they really makes sense, >> of they should get a forward compat tweak to 2.0 >> >> Yes, I agree with that and I've talked with Bernhard about that. He is >> going to dedicate again some time in the next coming months on Symfony >> and the form/validator sub-systems specifically. >> >> > 2) again from my POV composer is now in good enough shape that its not >> a show stopper anymore and of course people can continue to use the old >> vendors script. >> >> No question about that. Composer is now well integrated into the Symfony >> Standard Edition, and as far as I can see, everything is now working fine. >> >> > 3) i discussed briefly with Fabien in Denver about switching >> symfony/symfony to be a collection of submodules and making the >> component/bridge repo's the target for PR's. not sure if he has dropped the >> idea as it will make maintaining 2.0 a serious pain, but the benefit would >> be that for projects just using some components the contribution workflow >> would be a lot nicer >> >> see my other email about this specific topic >> >> > 4) i am unware of any major PR's that urgently need to get into 2.1 >> otherwise (though of course bug fixes should always come sooner rather than >> later) >> >> There are a couple of issues that needs to be resolved before a 2.1 >> stable. I have just created a new tag, "2.1 blocker". If you have an >> issue that you think is a real blocker for 2.1, please add this tag. But >> please, only use it for regressions, BC breaks that are not documented, >> or BC breaks that can be easily avoided. >> >> > so imho we should start discussing 1) on the list and then schedule a >> meeting for thursday next week (or whenever Bernhard and Fabien can both >> join) were we can discuss anything we couldnt resolve on the list. the >> following week we should then hopefully be able to publish a first RC (i >> dont think we need an alpha/beta phase). we should probably aim for 2-3 RC >> releases with a one week wait between, which should give us a stable >> release in the first half of may. >> >> I'm available on Thursday, but one hour earlier than our regular meeting >> schedule. >> >> I agree that we won't need any beta release and we can have RCs only. >> >> > this is already much later than we all had hoped back in december so i >> think its high time we get going with this release. >> >> agreed. >> >> Fabien >> >> > regards, >> > Lukas Kahwe Smith >> > [email protected] >> > >> > >> > >> > -- > 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 > -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com -- 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
