Is that not happening?
On Mon, Jun 2, 2014 at 11:26 AM, David Nalley <da...@gnsa.us> wrote: > 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 >
