On Tue, 2012-12-04 at 14:40 -0800, Josh Andler wrote:
On Tue, Dec 4, 2012 at 1:50 PM, Martin Owens <doctormo@...400...> wrote:
If we have a release schedule and we've reached a feature freeze, we should have branched into a release branch at that point. Trunk shouldn't ever be blocked with feature freezes, but instead making sure bugs get fixed in both trunk and release branches is a chore for us developers.
This is not how our development process has worked in the past. Which is why I put it forth as an idea to branch 0.49. We've previously opted to not actually branch for release until the release was ready as opposed to at freeze.
Perhaps we should put this proposed change in processes up to a vote (along with any other reasonable suggestions) a few days of waiting for feedback.
The concern has always been effectively dividing the workforce. If no one ends up making that release, what state are we in? Sure, Bazaar helps here, but it seems like the project suffers a bit overall. TBH, we have done that a bit in the past. Bryce did release management on 0.44 I believe on a branch in a similar style (as much as SVN allows it) and that was a frustration that he expressed.
Realistically, there's no difference to forking off a release branch and telling devs to keep their features on feature branches. In neither case is anyone "blocked" it's about naming really. So I don't think we should look at it as blocking anyone's progress either way.
Personally, I guess I want to see the release as "happening" which I think is the main concern. If it's well on it's way to being complete it's just baking and fixing, then sure, I'm for it. So what I'd propose is that we need to find people to assign to the bugs who are willing to take responsibility for fixing them. When they're all assigned, I think it might make sense to do a release branch.
--Ted