Sounds good to me. It won't necessarily mean much more work, since I assume that most branches won't have any merge conflicts.
Cheers, Daniel On Thu, Sep 8, 2016 at 6:36 PM, Stephen Mallette <[email protected]> wrote: > I think 3.3.0 will be a "big" release with many breaking changes as we > remove deprecation, upgrade certain dependencies, and make other usability > improvements. This won't be a release we want to rush as it affords us an > opportunity to make a number of things a lot better. I believe that we'd > discussed having 3.3.0 as a release for the end of 2016, but the more I > think about it, the more I wonder if that's enough time. > > Anyway, I think that if we hope to get a 3.3.0 out by end of 2016 or early > 2017, we will need to get started sooner than later. That of course, would > lead us to our branching model in git and how we will want to approach > that. > > Right now, things are pretty simple. We maintain master and tp31 branches > and tp31 merges one-way to master. If we want to start work on 3.3.0, then > I think we should begin a tp32 branch for the 3.2.x line of code and make > master be 3.3.x. Of course, that complicates our workflow slightly because > tp31 will need to merge to tp32 and then tp32 to master. While tp31 > development has ceased with the exception of bug fixes, I already find > divergence between tp31 and master as things stand today and that will only > get worse as we make breaking change to master. The point is that it may be > burdensome to merge tp32 to master at times for those other than the > original author of the work being merged. > > We may find that we may need a multi-pull request model to cleanly deal > with conflicts inherent to the merge. In other words, a change to tp31 > would mean a separate pull request to tp31, tp32 and master (as opposed to > one pull request to tp31 with a merge at some later time to tp32 and then > at some later time tp32 to master). For a change to tp32 you would just do > a PR to tp32 and a PR to master. That would be the safest way to deal with > conflicts and not have any surprises for some poor sap doing a blind merge > from one of our release branches down the line. > > Any thoughts on any of this? >
