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.
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.