[48/50] [abbrv] incubator-tinkerpop git commit: Added notes about the deprecation label to the dev docs.

[sp...@apache.org]

Added notes about the deprecation label to the dev docs.

This was done per discussion here: https://pony-poc.apache.org/thread.html/9dbdba0ad7970b2671d0a9b36ffa3d389a0125747bc84eea109ce1e7@1446038620@%3Cdev.tinkerpop.apache.org%3E


Project: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/commit/151f64b4
Tree: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/tree/151f64b4
Diff: http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/diff/151f64b4

Branch: refs/heads/TINKERPOP3-923
Commit: 151f64b4ee28f7ad5d097d347f27565409e9b6fd
Parents: b2daf09
Author: Stephen Mallette <sp...@genoprime.com>
Authored: Wed Nov 4 15:41:27 2015 -0500
Committer: Stephen Mallette <sp...@genoprime.com>
Committed: Wed Nov 4 15:41:27 2015 -0500

----------------------------------------------------------------------
 docs/src/developer-contributing.asciidoc | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/151f64b4/docs/src/developer-contributing.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/developer-contributing.asciidoc b/docs/src/developer-contributing.asciidoc
index fcdade0..dd4578f 100644
--- a/docs/src/developer-contributing.asciidoc
+++ b/docs/src/developer-contributing.asciidoc
@@ -165,8 +165,8 @@ Developers should remove their own branches when they are no longer needed.
 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
 ~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -187,9 +187,10 @@ reasonable workaround.  Given that definition, a `bug` should generally have ver
 ** 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 one exception: the "breaking" label.  The "breaking" label 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.
+* 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
@@ -217,14 +218,14 @@ replaced then the comment can simply read "not replaced".  Additional comments t
 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
+* All deprecation should typically 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.
+"breaking" label as well as a "deprecation" label.
+* Update the "upgrade documentation" to reflect the API change and how the reader should resolve it.
 
 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.