use of "breaking" label

[Stephen Mallette <sp...@gmail.com>]

I just fixed a bug in 3.0.1 for both TinkerGraph and Neo4jGraph:

https://issues.apache.org/jira/browse/TINKERPOP3-822

to validate the fix, i had to add a test to the test suite.  If other Graph
implementations followed the pattern that we used for those two graphs,
they will possibly have this bug too.  In which case, when they bump to
3.0.1, they will get test errors.

So, if you look at the issue, I added the "breaking" label to alert folks
to the fact that I added something that might break their implementation
when they bump to this version and wrote a fairly detailed comment to
explain why breaking might occur.

If we were to follow this pattern, it would likely mean that any changes to
the test suite would require a JIRA ticket with a "breaking" label.  As we
routinely add tests, I could see where we might see a bounce in the number
of JIRA issues around the "test-suite".

I also considered that if we did this, we might be watering down the
meaning of the "breaking" label, which I originally envisioned to be about
"breaking API changes".  Maybe a different label is needed for Graph
implementer breakage vs. API breakage?  I just don't want it to get
confusing.....i think that if there were multiple labels we'd want to be
sure they could represent mutually exclusive things to keep it simple.

Anyway, is this the way we want to use our "breaking" label?  Will this
help implementers of the core interfaces easily see what's different in a
release that they need to watch out for?  Will it be enough to help them
then resolve their issues in a relatively expedient fashion (as compared
with just bumping a version and getting a bunch of random test failures)?

For committers, are you good with this process - happy to add some extra
detail in JIRA around what we've defined as "breaking" change?