Related - have you considered using semantic versioning [1] (major.minor.patch)? Roughly, semver states that breaking changes should bump major, new backward-compatible features should bump minor while bug fixes should bump patch. It also supports pre-release version (-alpha, -incubating or -whatever suffixes).
In order to avoid having the first digit (major) being bumped too often (TP3 shall remain TP3!), a variation could be: marketing.major.minor.patch (downside to that is 4 digits versioning instead of 3). For example, adding a new Gremlin step would bump minor while changing a step signature in a backward-incompatible manner would bump major. semver is very popular in the JavaScript/Node.js world and used extensively with npm (node package manager). Just some thoughts. Jean-Baptiste [1] http://semver.org/ On Mon, Jul 13, 2015 at 1:20 PM, Stephen Mallette <[email protected]> wrote: > 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.
