I share that last concern. I have seen a lot of commits on the branch not matched by cherry-pick requests.
On Tue, May 27, 2014 at 11:16 PM, Marcus <[email protected]> wrote: > My impression was that we should change as little as possible once a > release is cut. We fix bugs, but we don't change code just to make it more > maintainable, for fear of introducing more bugs or regressing the known > state of the release. > > That aside, this fix is fairly minor so I'll probably just drop it. The > only question that remains is what people should do going forward when a > change needs to be made to an RC branch that is incompatible with its > "-forward" branch. > > > On Tue, May 27, 2014 at 2:23 PM, Daan Hoogland <[email protected]>wrote: > >> Marcus, >> >> I don't see why only fixes should go in 4.4. It should have been >> announced before feature freeze but there might be good reasons to >> refactor if it improves maintainability or removes bugs. You can >> revert the related commit and apply yours. or mix them. >> >> regards >> -- Daan
