Thanks JB - i'm familiar with semver and I think the idea is to follow it in principle, in that we will save API breaking change for the "minor" version. imo, we should stick to the three digit system for now but I guess it's worth considering what a "breaking change" is in our context.
TinkerPop is "big" - it has both public and internal APIs. if i change the package name of an internal API in a patch release, I wouldn't expect that to break anyone and thus I'm not sure I'd consider that a breaking change (though it's always interesting to see how folks find their way into using our internal classes) . To me the "breaking changes" are ones that occur in the public classes (i.e. the ones people are likely to use) like: gremlin driver classes, structure API for vendors, step classes and GraphTraversal/GraphTraversalSource, etc. Changing those classes in some way, would break the greatest percentage of users. I'm not sure how others feel, but I tend to think of "breaking change" in that more fuzzy fashion. On Wed, Jul 15, 2015 at 7:38 AM, Jean-Baptiste Musso <[email protected]> wrote: > 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. >
