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?
