bq. we instead focus on a releasable master +1
One of the hurdles to the above is that some unit tests in master are more flaky compared to their counterparts in branch-1. Smoothing out the flaky tests is non-trivial effort. On Mon, Mar 21, 2016 at 12:52 PM, Gary Helmling <ghelml...@gmail.com> wrote: > > > > Tho based on this discussion there's a bunch of good features that users > > want that won't fit the criteria for #1 and #2. So allowing a backport of > > the few that can fit into the criteria shouldn't significantly affect > > future release from trunk. This way we can have some progress on some > > features. > > > > > If we have features that don't fit criteria #1 (compatibility), then we > need a new major release according to our semver guidelines. Criteria #2 > (stability) I think needs to be a gating factor on any new feature coming > in. We need to be able to demonstrate that we're not doing any harm for > existing users by adding new features. > > In both cases, I'm not sure we're very well served by committing new > features to master, then back-porting to branch-1. That means that > whatever stabilization is happening is likely from testing on branch-1 > based releases and not master, giving more time for changes to diverge. I > think we would be better served by releasing early and often from master > and not having a branch-1 at all. That would serve as a forcing function > to make sure that change going in to master have to stabilize while "fresh" > before a release is made. > > For more complex efforts, it would be better to stabilize in a feature > branch and then merge the completed effort as one. > > I think we're already boxing ourselves in by looking at 2.0 as a feature > based release, which means it necessarily has an unbounded timeline. That > means we have to do backports for other features ready before then, since > master can't be released. If we instead focus on a releasable master, that > should help us release large changes more incrementally, and save ourselves > the hassle of so many backports at the same time. Of course everyone is > free to invest their time where they choose. But I think if we focus on > time-based releases instead it would be better for the project as a whole. >
