> > 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.
