Perhaps in the release process we could generate a JIRA report of issues marked as fixed in the specific version, and reserve the CHANGELOG for significant changes and things that were not tracked through JIRA.
On Thu, Jul 23, 2015 at 9:41 AM, Stephen Mallette <[email protected]> wrote: > We have typically treated CHANGELOG rather unscientifically. Make a change > of significance, then update the changelog for the appropriate version. I > bat around the idea of including the issue ids all the time but haven't > wanted to start the trend of doing that. Perhaps we do that and make it > optional?? Not sure how others feel on that matter. > > On Thu, Jul 23, 2015 at 11:35 AM, Matt Frantz <[email protected]> > wrote: > > > I just merged my fix for TINKERPOP3-782 to both tp30 and master. I > didn't > > touch CHANGELOG. Do we do that for every bug fix? I don't see > references > > to JIRA artifacts in the CHANGELOG. > > > > On Thu, Jul 23, 2015 at 3:59 AM, Stephen Mallette <[email protected]> > > wrote: > > > > > Hi Matt, > > > > > > 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. > > > > > > > > > > Right - no official code review. We pretty much tend to handle it as > you > > > just did - on a case-by-case basis. > > > > > > > > > > (I don't have permissions on the GitHub mirror for > > incubating-tinkerpop. > > > > Should I?) > > > > > > > > > > I don't think you should - I don't have permissions either. > > > > > > > > > > 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? > > > > > > > > > I've been the only person committing things to tp30 of any substance so > > > I've been doing it periodically, but generally speaking, I'd say that > > it's > > > best if the person who commits to tp30 merges to master (unless it's > > > something pretty trivial). In that way the person who committed to > tp30 > > is > > > responsible for ensuring proper integration with master. > > > > > > > > > > > > On Thu, Jul 23, 2015 at 12:19 AM, Matt Frantz < > > [email protected]> > > > wrote: > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > >
