I think it's worthwhile for us to do something we've not really done before with any of the TinkerPop projects: use branches. We typically tend to use branches for major refactoring that we might throw out, but not really for release management. As we look past release 3.0.0, I think we will want to have the capability to do more frequent minor releases (e.g. 3.0.1, 3.0.2, etc) while still being able to do work for a future 3.1.x line of code.
I think we can do this without too much change if we introduce a simple branch system. Release branch rules would be simple - we create a new branch from master called tp31 for the 3.1.x line of code. Any changes that are "breaking", introduce significant risk, a "major" feature, etc. would be committed there. All other changes, bug fixes, non-breaking refactoring of major APIs, "minor" features, etc. would simply commit to master. the master branch effectively becomes the 3.0.x line of code. Under this approach the merge process is pretty simple in that we just merge forward (i.e. master merges to to tp31). When the day comes that we're ready to release 3.1.0, we merge tp31 back to master and create tp32 and use the same model where the 3.1.x line is master and the 3.2.x line is tp32. Of course, under this model we are really supporting just the previous minor version, which for right now seems acceptable to me. That's more than what we've ever really done well, so that feels like a good starting point in my book. After we release 3.1.0 we can revisit and decide if a more complex branching strategy is needed.
