I have a PR currently targeted at tp30 (because it is a low-risk bug fix). I know that we don't necessarily code review everything that goes in, but since I'm relatively new, I wouldn't mind someone taking a peek at it, and the verify that tp30 is the best target.
(I don't have permissions on the GitHub mirror for incubating-tinkerpop. Should I?) Also, after it is merged to tp30, is the process going to be that I would also need to merge tp30 into master? Or do we plan to merge only occasionally? On Wed, Jul 15, 2015 at 5:19 AM, Stephen Mallette <[email protected]> wrote: > 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. > > >
