On Mon, Jun 2, 2014 at 1:21 PM, Marcus <shadow...@gmail.com> wrote: > I think many of the bullet points are what we are currently doing > (guidelines for commit comments, feature branches need to stay in sync with > master, no back-merging). I also think that much of what we do now is done > the way it is simply because there *are* vast changes between versions. > Classes are getting shuffled around and changed all the time. If its > feasible to merge branch fixes to master, that's fine, but some quick tests > seem to indicate that this will be messy getting started. > > That leaves us with how we do releases. I'm fine with having single > branches for major releases(4.3) and tagging the commits where each > incremental release (4.3.x) is done. I'm trying to remember why we went > with the -forward, I'm sure it's in the mailing list somewhere, but one of > the nice things it provides is the ability for the release manager to > control what changes are made during code freeze while giving people a > place to stage fixes (though admittedly this is not always followed). > Without -forward, would the flow be for each dev to have their own repo and > issue pull requests for bugfixes? >
The historical reasoning was that we needed to keep 4.x relatively clean, particularly as we were voting on RCs, but we didn't want to stop folks working on bugs, even if they were minor and getting those ready for 4.x.1; otherwise 4.x effectively becomes abandoned from a bug fix perspective. What should (IMO) be happening is 4.x-forward should be getting merged into 4.x as soon as the release is kicked out the door, and then 4.x-forward deleted. --David
