On 01/19/2017 01:43 PM, William A Rowe Jr wrote:
Once this is complete, binary breaking ABI changes would live in their own feature development forks. They would never be folded into trunk until there was a group consensus to push forward to version next.0.0 in the immediate future. trunk/ would cease to be a sandbox of ideas unready for release.
I can't comment meaningfully on all of your proposal, but I would like this part very much. Ideally, I'd like *most* changes (that are more complex than a single patch) to be part of a feature branch, whether they're ABI breakers or not, to help with backporting. But having trunk be closer to release-ready at all times would be a big step forward.
(Aside: my current experiment with a feature branch, for the in-tree tests in trunk, is somewhat inconclusive. I screwed up the invocations and used a deprecated merge strategy, and I suspect it won't backport as cleanly as I wanted it to. Live and learn.)
--Jacob
