On 6/8/12 7:30 PM, Bryan Call wrote:
I agree with John, I would rather only have and work on trunk and then make a
branch two weeks before a release.
Including feature freezing the trunk (master) for those 2 weeks? My
proposal was what you said, I think, but maybe I misunderstood? In my
proposal, the 3.3.x branch is the branch we work on in that 2 week
period, cherry-picking patches from trunk. In John's proposal, the work
flow is:
1. Two weeks before a dev release, trunk is closed for any and all
feature changes.
2. Bug fixes are allowed on trunk, but nothing else.
3. After 2 weeks, we tag trunk, and cut the release.
In my original proposal, the work flow would have been:
1. Two weeks before a dev release, we "git rebase" the 3.3.x branch from
master.
2. Work continues on trunk as before, mixing both features commits and
bug fixes freely. No restriction applies.
3. Bug fixes goes into the 3.3.x branch (git cherry-pick XYZ1234 onto
the 3.3.x branch).
4. After 2 weeks, we tag the 3.3.x branch, and cut the release.
I think John's proposal is much easier to manage, and this is how e.g.
Mozilla used to work (it probably still does?). When I proposed this
long time ago, there was resistance from feature freezing trunk. If
we're OK with that now, my vote would be to follow John's proposal, and
not worry about branching trunk at all, i.e. after the 2 week period, we
git tag the trunk for the development release, and open up the trunk for
new features again.
Let me know if I misunderstood either of your ideas :).
-- leif
