anchor.diff:  Tags
   ~~~~
   
  -Tags are used for milestones, release candidates, and approved releases.  Please
  -refrain from creating arbitrary tags, as they produce permanent clutter.
  +Tags are used for milestones, release candidates, and approved releases.  Please refrain from creating arbitrary
  +tags, as they produce permanent clutter.
   
   Issue Tracker Conventions
   ~~~~~~~~~~~~~~~~~~~~~~~~~
  
positive.code: encouraged.
  ** `@see <a href="https://issues.apache.org/jira/browse/TINKERPOP3-XXX">TINKERPOP3-XXX</a>` - supply a link to the
  JIRA issue for reference.
  * All deprecation should be tied to a JIRA issue with a "breaking" label - the issue itself does not need to
  specifically or solely be about "deprecation" but it should be documented very clearly in the comments what was
  deprecated and what the path forward should be.
  * Be sure that deprecated methods are still under test - consider using javadoc/comments in the tests themselves to
  call out this fact.
  * Create a new JIRA issue to track removal of the deprecation for future evaluation - this issue should have the
  "breaking" label.
  * Provide a post to the developers and/or users mailing lists as the case requires to alert the community to the change.
  
  The JIRA issues that track removal of deprecated methods should be periodically evaluated to determine if it is
  prudent to schedule them into a release.
  
negative.code: ** Everything else is an `improvement` in the sense that any other work is an enhancement to the current codebase.
  * The "component" should be representative of the primary area of code that it applies to and all issues should have
  this property set.
  * Issues are not assigned "labels" with two exceptions:
  ** The "breaking" label which marks an issue as one that is representative of a change in the API that might
  affect users or vendors.  This label is important when organizing release notes.
  ** The "deprecation" label which is assigned to an issue that is about removing a deprecated portion of the API.
  * The "affects/fix version(s)" fields should be appropriately set, where the "fix version" implies the version on
  which that particular issue will completed.
  * The "priority" field can be arbitrarily applied with one exception.  The "trivial" option should be reserved for
  