tinkerpop-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ok...@apache.org
Subject [14/50] incubator-tinkerpop git commit: TINKERPOP3-922 Created developer book.
Date Thu, 29 Oct 2015 23:29:35 GMT
TINKERPOP3-922 Created developer book.

Moved CONTRIBUTING and RELEASE to the developer book.


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

Branch: refs/heads/TINKERPOP3-925
Commit: 3a3fdf751263036fa0974bfc1f6da8e4faba8ddc
Parents: c8f1b70
Author: Stephen Mallette <spmva@genoprime.com>
Authored: Tue Oct 27 17:28:39 2015 -0400
Committer: Stephen Mallette <spmva@genoprime.com>
Committed: Tue Oct 27 17:28:39 2015 -0400

----------------------------------------------------------------------
 CONTRIBUTING.asciidoc                    | 246 +----------------------
 RELEASE.asciidoc                         | 172 -----------------
 docs/src/developer-contributing.asciidoc | 268 ++++++++++++++++++++++++++
 docs/src/developer-release.asciidoc      | 172 +++++++++++++++++
 docs/src/developer.asciidoc              |  29 +++
 pom.xml                                  |  29 ++-
 6 files changed, 499 insertions(+), 417 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/3a3fdf75/CONTRIBUTING.asciidoc
----------------------------------------------------------------------
diff --git a/CONTRIBUTING.asciidoc b/CONTRIBUTING.asciidoc
index 14825fa..e2439c1 100644
--- a/CONTRIBUTING.asciidoc
+++ b/CONTRIBUTING.asciidoc
@@ -22,247 +22,5 @@ author. By submitting any copyrighted material via pull request, email, or other
 you agree to license the material under the project's open source license and
 warrant that you have the legal authority to do so.
 
-Building and Testing
---------------------
-
-TinkerPop requires `Java 1.8.0_40+` for proper building and proper operations.
-
-* Build Project: `mvn clean install`
-** Specify specific tests in a TinkerPop Suite to run with the `GREMLIN_TESTS` environment variable, along with the
-Maven project list argument, e.g.:
-+
-----
-export GREMLIN_TESTS='org.apache.tinkerpop.gremlin.process.traversal.step.map.PathTest$Traversals,org.apache.tinkerpop.gremlin.process.traversal.PathTest'
-mvn -Dmaven.javadoc.skip=true --projects tinkergraph-gremlin test
-----
-** Clean the `.groovy/grapes/org.apache.tinkerpop` directory on build: `mvn clean install -DcleanGrapes`
-** Turn off "heavy" logging in the "process" tests: `mvn clean install -DargLine="-DmuteTestLogs=true"`
-** The test suite for `neo4j-gremlin` is disabled by default - to turn it on: `mvn clean install -DincludeNeo4j`
-* Regenerate test data (only necessary given changes to IO classes): `mvn clean install -Dio` from `tinkergraph-gremlin` directory
-** If there are changes to the Gryo format, it may be necessary to generate the Grateful Dead dataset from GraphSON (see `IoDataGenerationTest.shouldWriteGratefulDead`)
-* Check license headers are present: `mvn apache-rat:check`
-* Build AsciiDocs (Hadoop and ZooKeeper must be running): `bin/process-docs.sh`
-** Build AsciiDocs (but don't evaluate code blocks): `bin/process-docs.sh --dryRun`
-** Process a single AsciiDoc file: +pass:[docs/preprocessor/preprocess-file.sh `pwd`/gremlin-console/target/apache-gremlin-console-*-standalone `pwd`/docs/src/xyz.asciidoc]+
-* Build JavaDocs: `mvn process-resources -Djavadoc`
-* Check for Apache License headers: `mvn apache-rat:check`
-* Check for newer dependencies: `mvn versions:display-dependency-updates` or `mvn versions:display-plugin-updates`
-* Deploy JavaDocs/AsciiDocs: `bin/publish-docs.sh svn-username`
-* Integration Tests: `mvn verify -DskipIntegrationTests=false`
-** Execute with the `-DincludeNeo4j` option to include transactional tests.
-** Execute with the `-DuseEpoll` option to try to use Netty native transport (works on Linux, but will fallback to Java NIO on other OS).
-* Performance Tests: `mvn verify -DskipPerformanceTests=false`
-
-IDE Setup with Intellij
------------------------
-
-This section refers specifically to setup within Intellij.  TinkerPop has a module called `gremlin-shaded` which
-contains shaded dependencies for some libraries that are widely used and tend to introduce conflicts.  To ensure
-that Intellij properly interprets this module after importing the Maven `pom.xml` perform the following steps:
-
-. Build `gremlin-shaded` from the command line with `mvn clean install`.
-. Right-click on the `gremlin-shaded` module in the project viewer of Intellij and select "Remove module".
-. In the "Maven Projects" Tool window and click the tool button for "Reimport All Maven projects" (go to
-`View | Tool Windows | Maven Projects` on the main menu if this panel is not activated).
-. At this point it should be possible to compile and run the tests within Intellij, but in the worst case, use
-`File | Invalidate Caches/Restart` to ensure that indices properly rebuild.
-
-Note that it maybe be necessary to re-execute these steps if the `gremlin-shaded` `pom.xml` is ever updated.
-
-Developers working on the `neo4j-gremlin` module should enabled the `include-neo4j` Maven profile in Intellij.
-This will ensure that tests will properly execute within the IDE.
-
-If Intellij complains about "duplicate sources" for the Groovy files when attempting to compile/run tests, then
-install the link:http://plugins.jetbrains.com/plugin/7442?pr=idea[GMavenPlus Intellij plugin].
-
-For Committers
---------------
-
-The guidelines that follow apply to those with commit access to the main repository:
-
-Communication
-~~~~~~~~~~~~~
-
-TinkerPop has a link:http://groups.google.com/group/gremlin-users[user mailing list] and a
-link:http://mail-archives.apache.org/mod_mbox/incubator-tinkerpop-dev/[developer mailing list].  As a committer,
-it is a good idea to join both.
-
-It would also be helpful to join the public link:https://s.apache.org/tinkerpop[TinkerPop HipChat room] for developer
-discussion.  This helps contributors to communicate in a more real-time way.  Anyone can join as a guest, but for
-regular contributors it may be best to request that an Apache HipChat account be created.
-
-Release Notes
-~~~~~~~~~~~~~
-
-There is a two-pronged approach to maintaining the change log and preparing the release notes.
-
-1. For work that is documented in JIRA, run the release notes report to include all of
-the tickets targeted for a specific release.  This report can be included in the
-release announcement.
-
-2. The manual change log (`CHANGELOG.asciidoc`) can be used to highlight large
-changes, describe themes (e.g. "We focused on performance improvements") or to
-give voice to undocumented changes.
-
-Given the dependence on the JIRA report for generating additions to the `CHANGELOG.asciidoc`,
-which uses the title of the issue as the line presented in the release note report, titles should
-be edited prior to release to be useful in that context.  In other words, an issue title should
-be understandable as a change in the fewest words possible while still conveying the gist of the
-change.
-
-Changes that break the public APIs should be marked with a "breaking" label and should be
-distinguished from other changes in the release notes.
-
-Branches
-~~~~~~~~
-
-The "master" branch is used for the main line of development and release branches are constructed
-for ongoing maintenance work.  For example, the "tp30" branch is used to maintain the 3.0.x line
-while work on 3.1.x proceeds on "master".
-
-Other branches may be created for collaborating on features or for RFC's that
-other developers may want to inspect.  It is suggested that the JIRA issue ID be
-used as the prefix, since that triggers certain automation, and it provides a
-way to account for the branch lifecycle, i.e. "Who's branch is this, and can I
-delete it?"
-
-For branches that are NOT associated with JIRA issues, developers should utilize their Apache ID as
-a branch name prefix.  This provides a unique namespace, and also a way to account for the branch lifecycle.
-
-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.
-
-Issue Tracker Conventions
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-TinkerPop uses Apache JIRA as its link:https://issues.apache.org/jira/browse/TINKERPOP3[issue tracker].  JIRA is a
-very robust piece of software with many options and configurations.  To simplify usage and ensure consistency across
-issues, the following conventions should be adhered to:
-
-* An issue's "status" should generally be in one of two states: `open` or `closed` (`reopened` is equivalent to `open`
-for our purposes).
-** An `open` issue is newly created, under consideration or otherwise in progress.
-** A `closed` issue is completed for purposes of release (i.e. code, testing, and documentation complete).
-** Issues in a `resolved` state should immediately be evaluated for movement to `closed` - issue become `resolved`
-by those who don't have the permissions to `close`.
-* An issue's "type" should be one of two options: `bug` or `improvement`.
-** A `bug` has a very specific meaning, referring to an error that prevents usage of TinkerPop AND does not have a
-reasonable workaround.  Given that definition, a `bug` should generally have very high priority for a fix.
-** 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.
-* The "affects/fix version(s)" fields should be appropriately set, where the "fix version" implies the version on
-which that particular issue will completed.
-
-Code Style
-~~~~~~~~~~
-
-Contributors should examine the current code base to determine what the code style patterns are and should match their
-style to what is already present. Of specific note however, TinkerPop does not use "import wildcards" - IDEs should
-be adjusted accordingly to not auto-wildcard the imports.
-
-Deprecation
-~~~~~~~~~~~
-
-When possible, committers should avoid direct "breaking" change (e.g. removing a method from a class) and favor
-deprecation.  Deprecation should come with sufficient documentation and notice especially when the change involves
-public APIs that might be utilized by users or implemented by vendors:
-
-* Mark the code with the `@Deprecated` annotation.
-* Use javadoc to further document the change with the following content:
-** `@deprecated As of release x.y.z, replaced by {@link SomeOtherClass#someNewMethod()}` - if the method is not
-replaced then the comment can simply read "not replaced".  Additional comments that provide more context are
-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.
-
-Gremlin Language Test Cases
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-When writing a test case for a Gremlin step, be sure to use the following conventions.
-
-* The name of the traversal generator should start with `get`, use `X` for brackets, `_` for space, and the Gremlin-Groovy sugar syntax.
-** `get_g_V_hasLabelXpersonX_groupXaX_byXageX_byXsumX_name()`
-* When creating a test for a step that has both a barrier and sideEffect form (e.g. `group()`, `groupCount()`, etc.), test both representations.
-** `get_g_V_groupCount_byXnameX()`
-** `get_g_V_groupCountXaX_byXnameX_capXaX()`
-* The name of the actual test case should be the name of the traversal generator minus the `get_` prefix.
-* The Gremlin-Groovy version of the test should use the sugar syntax in order to test sugar (as Gremlin-Java8 tests test standard syntax).
-** `g.V.age.sum`
-* Avoid using lambdas in the test case unless that is explicitly what is being tested as OLAP systems will typically not be able to execute those tests.
-* `AbstractGremlinProcessTest` has various static methods to make writing a test case easy.
-** `checkResults(Arrays.asList("marko","josh"), traversal)`
-** `checkMap(new HashMap<String,Long>() {{ put("marko",1l); }}, traversal.next())`
-
-Review then Commit
-~~~~~~~~~~~~~~~~~~
-
-Code modifications must go through a link:http://www.apache.org/foundation/glossary.html#ReviewThenCommit[review-then-committ] (RTC)
-process before being merged into a release branch. All committers should follow the pattern below, where "you" refers to the
-committer wanting to put code into a release branch.
-
-* Make a JIRA ticket for the software problem you want to solve (i.e. a fix).
-* Fork the release branch that the fix will be put into.
-** The branch name should be the JIRA issue identifier (e.g. `TINKERPOP3-XXX`).
-* Develop your fix in your branch.
-* When your fix is complete and ready to merge, issue a link:https://git-scm.com/docs/git-request-pull[pull request].
-** Be certain that the test suite is passing.
-** If you updated documentation, be sure that the `process-docs.sh` is building the documentation correctly.
-* Before you can merge your branch into the release branch, you must have at least 3 +1 link:http://www.apache.org/foundation/glossary.html#ConsensusApproval[consensus votes].
-** Please see the Apache Software Foundations regulations regarding link:http://www.apache.org/foundation/voting.html#votes-on-code-modification[Voting on Code Modifications].
-* Votes are issued by TinkerPop committers as comments to the pull request.
-* Once 3 +1 votes are received, you are responsible for merging to the release branch and handling any merge conflicts.
-** If there is a higher version release branch that requires your fix (e.g. `3.y-1.z` fix going to a `3.y.z` release), be sure to merge to that release branch as well.
-* Be conscious of deleting your branch if it is no longer going to be used so stale branches don't pollute the repository.
-
-NOTE: These steps also generally apply to external pull requests from those who are not official Apache committers. In
-this case, the person responsible for the merge after voting is typically the first person available
-who is knowledgeable in the area that the pull request affects. Any additional coordination on merging can be handled
-via the pull request comment system.
-
-The following exceptions to the RTC (review-then-commit) model presented above are itemized below. It is up to the
-committer to self-regulate as the itemization below is not complete and only hints and the types of commits that do not
-require a review.
-
-* You are responsible for a release and need to manipulate files accordingly for the release.
-** `Gremlin.version()`, CHANGELOG dates, `pom.xml` version bumps, etc.
-* You are doing an minor change and it is obvious that an RTC is not required (would be a pointless burden to the community).
-** The fix is under the link:http://www.apache.org/foundation/glossary.html#CommitThenReview[commit-then-review] (CTR) policy and lazy consensus is sufficient, where a single -1 vote requires you to revert your changes.
-** Adding a test case, fixing spelling/grammar mistakes in the documentation, fixing LICENSE/NOTICE/etc. files, fixing a minor issue in an already merged branch.
-
-Pull Request Format
-^^^^^^^^^^^^^^^^^^^
-
-When you submit a pull request, be sure it uses the following style.
-
-* The title of the pull request is the JIRA ticket number + "colon" + the title of the JIRA ticket.
-* The first line of the pull request message should contain a link to the JIRA ticket.
-* Discuss what you did to solve the problem articulated in the JIRA ticket.
-* Discuss any "extra" work done that go beyond the assumed requirements of the JIRA ticket.
-* Be sure to explain what you did to prove that the issue is resolved.
-** Test cases written.
-** Integration tests run (if required for the work accomplished).
-** Documentation building (if required for the work accomplished).
-** Any manual testing (though this should be embodied in a test case).
-* Notes about what you will do when you merge to the respective release branch (e.g. update CHANGELOG).
-** These types of "on merge tweaks" are typically done to extremely dynamic files to combat and merge conflicts.
-* If you are a TinkerPop committer, you can VOTE on your own pull request, so please do so.
+Please see the "Developer Documentation" for more information on
+link:http://tinkerpop.incubator.apache.org/docs/3.1.0-SNAPSHOT/developer.html#_contributing[contributing] to TinkerPop.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/3a3fdf75/RELEASE.asciidoc
----------------------------------------------------------------------
diff --git a/RELEASE.asciidoc b/RELEASE.asciidoc
deleted file mode 100644
index bb3b69a..0000000
--- a/RELEASE.asciidoc
+++ /dev/null
@@ -1,172 +0,0 @@
-////
-Licensed to the Apache Software Foundation (ASF) under one or more
-contributor license agreements.  See the NOTICE file distributed with
-this work for additional information regarding copyright ownership.
-The ASF licenses this file to You under the Apache License, Version 2.0
-(the "License"); you may not use this file except in compliance with
-the License.  You may obtain a copy of the License at
-
-  http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-////
-Release Process
----------------
-
-This document describes the steps required to release a version of TinkerPop.  The release is handled by a "release
-manager" (a committer fulfills this role), who ensures that the steps in this document are executed. The process is
-multi-phased and can therefore take several weeks to complete given the time needed for Apache voting and community
-feedback.  Once a release point has been identified, the following phases represent the flow of "release":
-
-* Pre-flight check.
-* Optionally, produce a release candidate for community feedback.
-* Submit the official release for PMC vote.
-* Submit the official release for Incubator vote.
-* Release and promote.
-
-Pre-flight Check
-~~~~~~~~~~~~~~~~
-
-The "pre-flight check" is a list of things performed by the release manager during the weeks leading up to a scheduled
-day to release.  These checks will help to ensure that that release day goes smoothly by identifying problems up early
-and communicating with other members of the community.
-
-. Fourteen days before release, issue an email to the dev mailing list to remind the community of the pending release.
-.. Note any important issues open in JIRA in that post.
-.. Request review and update of the "upgrade documentation" and CHANGELOG.
-. Seven days before release, announce the code freeze on the dev mailing list to remind the community that the branch
-under release is protected. Tweaks to documentation and other odds and ends related to release are still allowed
-during this period.
-. At some point during the week:
-.. Deploy a final SNAPSHOT to the snapshot repository.
-.. Review LICENSE and NOTICE files to make sure that no changes are needed.
-.. Review javadoc filters on the "Core API" docs to be sure nothing needs to change.
-. When all documentation changes are in place, use `bin/publish-docs.sh` to deploy a final `SNAPSHOT` representation
-of the docs and thus validate that there are no issues with the documentation generation process. Request review
-of the published documentation on the dev mailing list.
-
-Release Candidate
-~~~~~~~~~~~~~~~~~
-
-A release candidate is an unofficial release that is represented by a tagged version in the Git repository.  It is
-offered in cases where there is significant change in a particular version and the potential for upgrades and problems
-might be high.
-
-. `mvn clean install -DincludeNeo4j`
-.. `mvn verify -DskipIntegrationTests=false -DincludeNeo4j`
-.. `mvn verify -DskipPerformanceTests=false`
-. `bin/publish-docs.sh <username>` - note that under a release candidate the documentation is published as SNAPSHOT
-. `mvn versions:set -DnewVersion=x.y.z -DgenerateBackupPoms=false` to update the project files to reference a non-SNAPSHOT version
-. `git diff` and review the updated files (expect all `pom.xml` files and this README)
-. `git commit -a -m "TinkerPop x.y.z release"` and `git push`
-. `git tag -a -m "TinkerPop x.y.z release" x.y.z` and `git push --tags`
-. `mvn clean install -Dmaven.test.skip=true`
-. `mvn versions:set -DnewVersion=x.y.z-SNAPSHOT -DgenerateBackupPoms=false` to go back to SNAPSHOT
-. `git commit -a -m "Returned to x.y.z-SNAPSHOT"` and `git push`
-. Announce the release candidate to `dev` mailing list and await feedback
-. Repeat as required or proceed to the next phase
-
-PMC Vote
-~~~~~~~~
-
-A positive vote for a particular release from the TinkerPop PMC is required to move to the following phase.
-
-. `mvn clean install`
-.. `mvn verify -DskipIntegrationTests=false -DincludeNeo4j`
-.. `mvn verify -DskipPerformanceTests=false`
-. Perform manual tests:
-.. Execute `:remote connect conf/remote.yaml` and send some requests to a running Gremlin Server instance.
-.. Execute `:?` to display the help in the Console.
-. Update `CHANGELOG.asciidoc`:
-.. Update the release date
-.. Generate the JIRA release notes report for the current version and append them to the `CHANGELOG.asciidoc`
-.. Organize "breaking" changes to be clearly marked (use JIRA and the "breaking" label to identify those)
-. Update "upgrade documentation":
-.. Update the release date.
-.. Update the link to CHANGELOG.asciidoc
-. `mvn versions:set -DnewVersion=x.y.z -DgenerateBackupPoms=false` to update project files to reference the non-SNAPSHOT version
-. `git diff` and review the updated files (expect all `pom.xml` files and this README)
-. `git commit -a -m "TinkerPop x.y.z release"` and `git push`
-. `git tag -a -m "TinkerPop x.y.z release" x.y.z` and `git push --tags`
-. `mvn clean install -Dmaven.test.skip=true`
-. `bin/publish-docs.sh <username>`
-. `mvn install -Papache-release -DcreateChecksum=true -Dmaven.test.skip=true`
-. Review generated artifacts to be sure they have both javadocs and asciidocs present
-. Upload artifacts to `https://dist.apache.org/repos/dist/dev/incubator/tinkerpop` for `[VOTE]` review.
-.. `svn co --depth empty https://dist.apache.org/repos/dist/dev/incubator/tinkerpop/ dev` and `mkdir dev/x.y.z`
-.. `cp ~/.m2/repository/org/apache/tinkerpop/gremlin-console/x.y.z/gremlin-console-x.y.z-distribution.zip* dev/x.y.z`
-.. `cp ~/.m2/repository/org/apache/tinkerpop/gremlin-server/x.y.z/gremlin-server-x.y.z-distribution.zip* dev/x.y.z`
-.. `cp ~/.m2/repository/org/apache/tinkerpop/tinkerpop/x.y.z/tinkerpop-x.y.z-source-release.zip* dev/x.y.z`
-.. `cd dev/x.y.z` and `for f in \*.zip*; do  mv "$f" "apache-$f"; done`
-.. `cd ..; svn add x.y.z/; svn ci -m "TinkerPop x.y.z release"`
-. Execute `bin/validate-distribution.sh` and any other relevant testing.
-. Perform JIRA administration tasks:
-.. "Release" the current version and set the "release date"
-.. If there is to be a follow on release in the current line of code, create that new version specifying the "start date"
-.. Migrate the "Affected Version" of all unresolved issues to the next lowest common denominator version - if version 3.0.1 released then all 3.0.0 issues should move forward to 3.0.1 as they now "affect" that latest release
-. Submit for `[VOTE]` at `dev@tinkerpop.incubator.apache.org` (see email template below)
-. *Wait for vote acceptance* (72 hours)
-
-Incubator Vote
-~~~~~~~~~~~~~~
-
-A positive vote for a particular release from the Apache Incubator is required to move to the following phase.
-
-. Submit for `[VOTE]` at `general@incubator.apache.org` (see email template below)
-.. Include the vote tally: "Apache TinkerPop (http://tinkerpop.incubator.apache.org/) would like to release TinkerPop x.y.z. We had a dev@ VOTE which resulted in a tally of +1 (3), 0 (0), and -1 (0). We now present our artifacts for vote by Incubator."
-. *Wait for vote acceptance* (72 hours)
-
-Release & Promote
-~~~~~~~~~~~~~~~~~
-
-. `mvn clean install -Djavadoc -Dmaven.test.skip=true; bin/process-docs.sh` - rebuild source and docs of tagged release
-. `mvn deploy -Papache-release -DcreateChecksum=true -Dmaven.test.skip=true`- deploy signed artifacts with checksums to Apache Nexus
-. Review and close the staging repository (Apache Nexus at link:https://repository.apache.org/[https://repository.apache.org/]) - check that versions are correct and that all artifacts are present
-. `svn co --depth empty https://dist.apache.org/repos/dist/dev/incubator/tinkerpop dev; svn up dev/x.y.z`
-. `svn co --depth empty https://dist.apache.org/repos/dist/release/incubator/tinkerpop release; mkdir release/x.y.z`
-. `ls dev/x.y.z/ | grep '\-\(distribution\|source\-release\)\.zip' | sed -e 's/\(^[^ ]\*\)-distribution\([^ ]*\)/cp dev\/x.y.z\/\0 release\/x.y.z\/\1-bin\2/' -e 's/\(^[^ ]\*\)-source-release\([^ ]*\)/cp dev\/x.y.z\/\0 release\/x.y.z\/\1-src\2/' | /bin/sh`
-. `cd release; svn add x.y.z/; svn ci -m "TinkerPop x.y.z release"`
-. Update homepage with references to latest distribution and to other internal links elsewhere on the page.
-. Wait for Apache Central to sync the jars and src (link:http://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/[http://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/]).
-. Announce release on `dev@`/`gremlin-users@` mailing lists and tweet from `@apachetinkerpop`
-
-Example `[VOTE]` email:
-
-```
-[VOTE] TinkerPop x.y.z Release
-
-Hello,
-
-The release artifacts can be found at this location:
-	https://dist.apache.org/repos/dist/dev/incubator/tinkerpop/x.y.z/
-
-The source distribution is provided by:
-	apache-tinkerpop-x.y.z-source-release.zip
-
-Two binary distributions are provided for user convenience:
-	apache-gremlin-console-x.y.z-distribution.zip
-	apache-gremlin-server-x.y.z-distribution.zip
-
-The online docs can be found here:
-	http://tinkerpop.incubator.apache.org/docs/x.y.z/ (user docs)
-	http://tinkerpop.incubator.apache.org/docs/x.y.z/upgrade.html (upgrade docs)
-	http://tinkerpop.incubator.apache.org/javadocs/x.y.z/core/ (core javadoc)
-	http://tinkerpop.incubator.apache.org/javadocs/x.y.z/full/ (full javadoc)
-
-The tag in Apache Git can be found here:
-	https://git-wip-us.apache.org/repos/asf?p=incubator-tinkerpop.git;...
-
-The release notes are available here:
-	https://github.com/apache/incubator-tinkerpop/blob/master/CHANGELOG.asciidoc#...
-
-The [VOTE] will be open for the next 72 hours --- closing <DayOfTheWeek> (<Month> <Day> <Year>) at <Time> <TimeZone>.
-
-My vote is +1.
-
-Thank you very much,
-<TinkerPop Committer Name>
-```
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/3a3fdf75/docs/src/developer-contributing.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/developer-contributing.asciidoc b/docs/src/developer-contributing.asciidoc
new file mode 100644
index 0000000..dfa9d28
--- /dev/null
+++ b/docs/src/developer-contributing.asciidoc
@@ -0,0 +1,268 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+////
+Contributing
+============
+
+Contributions via GitHub pull requests are gladly accepted from their original
+author. By submitting any copyrighted material via pull request, email, or other means
+you agree to license the material under the project's open source license and
+warrant that you have the legal authority to do so.
+
+Building and Testing
+--------------------
+
+TinkerPop requires `Java 1.8.0_40+` for proper building and proper operations.
+
+* Build Project: `mvn clean install`
+** Specify specific tests in a TinkerPop Suite to run with the `GREMLIN_TESTS` environment variable, along with the
+Maven project list argument, e.g.:
++
+----
+export GREMLIN_TESTS='org.apache.tinkerpop.gremlin.process.traversal.step.map.PathTest$Traversals,org.apache.tinkerpop.gremlin.process.traversal.PathTest'
+mvn -Dmaven.javadoc.skip=true --projects tinkergraph-gremlin test
+----
+** Clean the `.groovy/grapes/org.apache.tinkerpop` directory on build: `mvn clean install -DcleanGrapes`
+** Turn off "heavy" logging in the "process" tests: `mvn clean install -DargLine="-DmuteTestLogs=true"`
+** The test suite for `neo4j-gremlin` is disabled by default - to turn it on: `mvn clean install -DincludeNeo4j`
+* Regenerate test data (only necessary given changes to IO classes): `mvn clean install -Dio` from `tinkergraph-gremlin` directory
+** If there are changes to the Gryo format, it may be necessary to generate the Grateful Dead dataset from GraphSON (see `IoDataGenerationTest.shouldWriteGratefulDead`)
+* Check license headers are present: `mvn apache-rat:check`
+* Build AsciiDocs (Hadoop and ZooKeeper must be running): `bin/process-docs.sh`
+** Build AsciiDocs (but don't evaluate code blocks): `bin/process-docs.sh --dryRun`
+** Process a single AsciiDoc file: +pass:[docs/preprocessor/preprocess-file.sh `pwd`/gremlin-console/target/apache-gremlin-console-*-standalone `pwd`/docs/src/xyz.asciidoc]+
+* Build JavaDocs: `mvn process-resources -Djavadoc`
+* Check for Apache License headers: `mvn apache-rat:check`
+* Check for newer dependencies: `mvn versions:display-dependency-updates` or `mvn versions:display-plugin-updates`
+* Deploy JavaDocs/AsciiDocs: `bin/publish-docs.sh svn-username`
+* Integration Tests: `mvn verify -DskipIntegrationTests=false`
+** Execute with the `-DincludeNeo4j` option to include transactional tests.
+** Execute with the `-DuseEpoll` option to try to use Netty native transport (works on Linux, but will fallback to Java NIO on other OS).
+* Performance Tests: `mvn verify -DskipPerformanceTests=false`
+
+IDE Setup with Intellij
+-----------------------
+
+This section refers specifically to setup within Intellij.  TinkerPop has a module called `gremlin-shaded` which
+contains shaded dependencies for some libraries that are widely used and tend to introduce conflicts.  To ensure
+that Intellij properly interprets this module after importing the Maven `pom.xml` perform the following steps:
+
+. Build `gremlin-shaded` from the command line with `mvn clean install`.
+. Right-click on the `gremlin-shaded` module in the project viewer of Intellij and select "Remove module".
+. In the "Maven Projects" Tool window and click the tool button for "Reimport All Maven projects" (go to
+`View | Tool Windows | Maven Projects` on the main menu if this panel is not activated).
+. At this point it should be possible to compile and run the tests within Intellij, but in the worst case, use
+`File | Invalidate Caches/Restart` to ensure that indices properly rebuild.
+
+Note that it maybe be necessary to re-execute these steps if the `gremlin-shaded` `pom.xml` is ever updated.
+
+Developers working on the `neo4j-gremlin` module should enabled the `include-neo4j` Maven profile in Intellij.
+This will ensure that tests will properly execute within the IDE.
+
+If Intellij complains about "duplicate sources" for the Groovy files when attempting to compile/run tests, then
+install the link:http://plugins.jetbrains.com/plugin/7442?pr=idea[GMavenPlus Intellij plugin].
+
+For Committers
+--------------
+
+The guidelines that follow apply to those with commit access to the main repository:
+
+Communication
+~~~~~~~~~~~~~
+
+TinkerPop has a link:http://groups.google.com/group/gremlin-users[user mailing list] and a
+link:http://mail-archives.apache.org/mod_mbox/incubator-tinkerpop-dev/[developer mailing list].  As a committer,
+it is a good idea to join both.
+
+It would also be helpful to join the public link:https://s.apache.org/tinkerpop[TinkerPop HipChat room] for developer
+discussion.  This helps contributors to communicate in a more real-time way.  Anyone can join as a guest, but for
+regular contributors it may be best to request that an Apache HipChat account be created.
+
+Release Notes
+~~~~~~~~~~~~~
+
+There is a two-pronged approach to maintaining the change log and preparing the release notes.
+
+1. For work that is documented in JIRA, run the release notes report to include all of
+the tickets targeted for a specific release.  This report can be included in the
+release announcement.
+
+2. The manual change log (`CHANGELOG.asciidoc`) can be used to highlight large
+changes, describe themes (e.g. "We focused on performance improvements") or to
+give voice to undocumented changes.
+
+Given the dependence on the JIRA report for generating additions to the `CHANGELOG.asciidoc`,
+which uses the title of the issue as the line presented in the release note report, titles should
+be edited prior to release to be useful in that context.  In other words, an issue title should
+be understandable as a change in the fewest words possible while still conveying the gist of the
+change.
+
+Changes that break the public APIs should be marked with a "breaking" label and should be
+distinguished from other changes in the release notes.
+
+Branches
+~~~~~~~~
+
+The "master" branch is used for the main line of development and release branches are constructed
+for ongoing maintenance work.  For example, the "tp30" branch is used to maintain the 3.0.x line
+while work on 3.1.x proceeds on "master".
+
+Other branches may be created for collaborating on features or for RFC's that
+other developers may want to inspect.  It is suggested that the JIRA issue ID be
+used as the prefix, since that triggers certain automation, and it provides a
+way to account for the branch lifecycle, i.e. "Who's branch is this, and can I
+delete it?"
+
+For branches that are NOT associated with JIRA issues, developers should utilize their Apache ID as
+a branch name prefix.  This provides a unique namespace, and also a way to account for the branch lifecycle.
+
+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.
+
+Issue Tracker Conventions
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TinkerPop uses Apache JIRA as its link:https://issues.apache.org/jira/browse/TINKERPOP3[issue tracker].  JIRA is a
+very robust piece of software with many options and configurations.  To simplify usage and ensure consistency across
+issues, the following conventions should be adhered to:
+
+* An issue's "status" should generally be in one of two states: `open` or `closed` (`reopened` is equivalent to `open`
+for our purposes).
+** An `open` issue is newly created, under consideration or otherwise in progress.
+** A `closed` issue is completed for purposes of release (i.e. code, testing, and documentation complete).
+** Issues in a `resolved` state should immediately be evaluated for movement to `closed` - issue become `resolved`
+by those who don't have the permissions to `close`.
+* An issue's "type" should be one of two options: `bug` or `improvement`.
+** A `bug` has a very specific meaning, referring to an error that prevents usage of TinkerPop AND does not have a
+reasonable workaround.  Given that definition, a `bug` should generally have very high priority for a fix.
+** 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.
+* The "affects/fix version(s)" fields should be appropriately set, where the "fix version" implies the version on
+which that particular issue will completed.
+
+Code Style
+~~~~~~~~~~
+
+Contributors should examine the current code base to determine what the code style patterns are and should match their
+style to what is already present. Of specific note however, TinkerPop does not use "import wildcards" - IDEs should
+be adjusted accordingly to not auto-wildcard the imports.
+
+Deprecation
+~~~~~~~~~~~
+
+When possible, committers should avoid direct "breaking" change (e.g. removing a method from a class) and favor
+deprecation.  Deprecation should come with sufficient documentation and notice especially when the change involves
+public APIs that might be utilized by users or implemented by vendors:
+
+* Mark the code with the `@Deprecated` annotation.
+* Use javadoc to further document the change with the following content:
+** `@deprecated As of release x.y.z, replaced by {@link SomeOtherClass#someNewMethod()}` - if the method is not
+replaced then the comment can simply read "not replaced".  Additional comments that provide more context are
+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.
+
+Gremlin Language Test Cases
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When writing a test case for a Gremlin step, be sure to use the following conventions.
+
+* The name of the traversal generator should start with `get`, use `X` for brackets, `_` for space, and the Gremlin-Groovy sugar syntax.
+** `get_g_V_hasLabelXpersonX_groupXaX_byXageX_byXsumX_name()`
+* When creating a test for a step that has both a barrier and sideEffect form (e.g. `group()`, `groupCount()`, etc.), test both representations.
+** `get_g_V_groupCount_byXnameX()`
+** `get_g_V_groupCountXaX_byXnameX_capXaX()`
+* The name of the actual test case should be the name of the traversal generator minus the `get_` prefix.
+* The Gremlin-Groovy version of the test should use the sugar syntax in order to test sugar (as Gremlin-Java8 tests test standard syntax).
+** `g.V.age.sum`
+* Avoid using lambdas in the test case unless that is explicitly what is being tested as OLAP systems will typically not be able to execute those tests.
+* `AbstractGremlinProcessTest` has various static methods to make writing a test case easy.
+** `checkResults(Arrays.asList("marko","josh"), traversal)`
+** `checkMap(new HashMap<String,Long>() {{ put("marko",1l); }}, traversal.next())`
+
+Review then Commit
+~~~~~~~~~~~~~~~~~~
+
+Code modifications must go through a link:http://www.apache.org/foundation/glossary.html#ReviewThenCommit[review-then-committ] (RTC)
+process before being merged into a release branch. All committers should follow the pattern below, where "you" refers to the
+committer wanting to put code into a release branch.
+
+* Make a JIRA ticket for the software problem you want to solve (i.e. a fix).
+* Fork the release branch that the fix will be put into.
+** The branch name should be the JIRA issue identifier (e.g. `TINKERPOP3-XXX`).
+* Develop your fix in your branch.
+* When your fix is complete and ready to merge, issue a link:https://git-scm.com/docs/git-request-pull[pull request].
+** Be certain that the test suite is passing.
+** If you updated documentation, be sure that the `process-docs.sh` is building the documentation correctly.
+* Before you can merge your branch into the release branch, you must have at least 3 +1 link:http://www.apache.org/foundation/glossary.html#ConsensusApproval[consensus votes].
+** Please see the Apache Software Foundations regulations regarding link:http://www.apache.org/foundation/voting.html#votes-on-code-modification[Voting on Code Modifications].
+* Votes are issued by TinkerPop committers as comments to the pull request.
+* Once 3 +1 votes are received, you are responsible for merging to the release branch and handling any merge conflicts.
+** If there is a higher version release branch that requires your fix (e.g. `3.y-1.z` fix going to a `3.y.z` release), be sure to merge to that release branch as well.
+* Be conscious of deleting your branch if it is no longer going to be used so stale branches don't pollute the repository.
+
+NOTE: These steps also generally apply to external pull requests from those who are not official Apache committers. In
+this case, the person responsible for the merge after voting is typically the first person available
+who is knowledgeable in the area that the pull request affects. Any additional coordination on merging can be handled
+via the pull request comment system.
+
+The following exceptions to the RTC (review-then-commit) model presented above are itemized below. It is up to the
+committer to self-regulate as the itemization below is not complete and only hints and the types of commits that do not
+require a review.
+
+* You are responsible for a release and need to manipulate files accordingly for the release.
+** `Gremlin.version()`, CHANGELOG dates, `pom.xml` version bumps, etc.
+* You are doing an minor change and it is obvious that an RTC is not required (would be a pointless burden to the community).
+** The fix is under the link:http://www.apache.org/foundation/glossary.html#CommitThenReview[commit-then-review] (CTR) policy and lazy consensus is sufficient, where a single -1 vote requires you to revert your changes.
+** Adding a test case, fixing spelling/grammar mistakes in the documentation, fixing LICENSE/NOTICE/etc. files, fixing a minor issue in an already merged branch.
+
+Pull Request Format
+^^^^^^^^^^^^^^^^^^^
+
+When you submit a pull request, be sure it uses the following style.
+
+* The title of the pull request is the JIRA ticket number + "colon" + the title of the JIRA ticket.
+* The first line of the pull request message should contain a link to the JIRA ticket.
+* Discuss what you did to solve the problem articulated in the JIRA ticket.
+* Discuss any "extra" work done that go beyond the assumed requirements of the JIRA ticket.
+* Be sure to explain what you did to prove that the issue is resolved.
+** Test cases written.
+** Integration tests run (if required for the work accomplished).
+** Documentation building (if required for the work accomplished).
+** Any manual testing (though this should be embodied in a test case).
+* Notes about what you will do when you merge to the respective release branch (e.g. update CHANGELOG).
+** These types of "on merge tweaks" are typically done to extremely dynamic files to combat and merge conflicts.
+* If you are a TinkerPop committer, you can VOTE on your own pull request, so please do so.

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/3a3fdf75/docs/src/developer-release.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/developer-release.asciidoc b/docs/src/developer-release.asciidoc
new file mode 100644
index 0000000..e2b7eeb
--- /dev/null
+++ b/docs/src/developer-release.asciidoc
@@ -0,0 +1,172 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+////
+Release Process
+===============
+
+This document describes the steps required to release a version of TinkerPop.  The release is handled by a "release
+manager" (a committer fulfills this role), who ensures that the steps in this document are executed. The process is
+multi-phased and can therefore take several weeks to complete given the time needed for Apache voting and community
+feedback.  Once a release point has been identified, the following phases represent the flow of "release":
+
+* Pre-flight check.
+* Optionally, produce a release candidate for community feedback.
+* Submit the official release for PMC vote.
+* Submit the official release for Incubator vote.
+* Release and promote.
+
+Pre-flight Check
+----------------
+
+The "pre-flight check" is a list of things performed by the release manager during the weeks leading up to a scheduled
+day to release.  These checks will help to ensure that that release day goes smoothly by identifying problems up early
+and communicating with other members of the community.
+
+. Fourteen days before release, issue an email to the dev mailing list to remind the community of the pending release.
+.. Note any important issues open in JIRA in that post.
+.. Request review and update of the "upgrade documentation" and CHANGELOG.
+. Seven days before release, announce the code freeze on the dev mailing list to remind the community that the branch
+under release is protected. Tweaks to documentation and other odds and ends related to release are still allowed
+during this period.
+. At some point during the week:
+.. Deploy a final SNAPSHOT to the snapshot repository.
+.. Review LICENSE and NOTICE files to make sure that no changes are needed.
+.. Review javadoc filters on the "Core API" docs to be sure nothing needs to change.
+. When all documentation changes are in place, use `bin/publish-docs.sh` to deploy a final `SNAPSHOT` representation
+of the docs and thus validate that there are no issues with the documentation generation process. Request review
+of the published documentation on the dev mailing list.
+
+Release Candidate
+-----------------
+
+A release candidate is an unofficial release that is represented by a tagged version in the Git repository.  It is
+offered in cases where there is significant change in a particular version and the potential for upgrades and problems
+might be high.
+
+. `mvn clean install -DincludeNeo4j`
+.. `mvn verify -DskipIntegrationTests=false -DincludeNeo4j`
+.. `mvn verify -DskipPerformanceTests=false`
+. `bin/publish-docs.sh <username>` - note that under a release candidate the documentation is published as SNAPSHOT
+. `mvn versions:set -DnewVersion=x.y.z -DgenerateBackupPoms=false` to update the project files to reference a non-SNAPSHOT version
+. `git diff` and review the updated files (expect all `pom.xml` files and this README)
+. `git commit -a -m "TinkerPop x.y.z release"` and `git push`
+. `git tag -a -m "TinkerPop x.y.z release" x.y.z` and `git push --tags`
+. `mvn clean install -Dmaven.test.skip=true`
+. `mvn versions:set -DnewVersion=x.y.z-SNAPSHOT -DgenerateBackupPoms=false` to go back to SNAPSHOT
+. `git commit -a -m "Returned to x.y.z-SNAPSHOT"` and `git push`
+. Announce the release candidate to `dev` mailing list and await feedback
+. Repeat as required or proceed to the next phase
+
+PMC Vote
+--------
+
+A positive vote for a particular release from the TinkerPop PMC is required to move to the following phase.
+
+. `mvn clean install`
+.. `mvn verify -DskipIntegrationTests=false -DincludeNeo4j`
+.. `mvn verify -DskipPerformanceTests=false`
+. Perform manual tests:
+.. Execute `:remote connect conf/remote.yaml` and send some requests to a running Gremlin Server instance.
+.. Execute `:?` to display the help in the Console.
+. Update `CHANGELOG.asciidoc`:
+.. Update the release date
+.. Generate the JIRA release notes report for the current version and append them to the `CHANGELOG.asciidoc`
+.. Organize "breaking" changes to be clearly marked (use JIRA and the "breaking" label to identify those)
+. Update "upgrade documentation":
+.. Update the release date.
+.. Update the link to CHANGELOG.asciidoc
+. `mvn versions:set -DnewVersion=x.y.z -DgenerateBackupPoms=false` to update project files to reference the non-SNAPSHOT version
+. `git diff` and review the updated files (expect all `pom.xml` files and this README)
+. `git commit -a -m "TinkerPop x.y.z release"` and `git push`
+. `git tag -a -m "TinkerPop x.y.z release" x.y.z` and `git push --tags`
+. `mvn clean install -Dmaven.test.skip=true`
+. `bin/publish-docs.sh <username>`
+. `mvn install -Papache-release -DcreateChecksum=true -Dmaven.test.skip=true`
+. Review generated artifacts to be sure they have both javadocs and asciidocs present
+. Upload artifacts to `https://dist.apache.org/repos/dist/dev/incubator/tinkerpop` for `[VOTE]` review.
+.. `svn co --depth empty https://dist.apache.org/repos/dist/dev/incubator/tinkerpop/ dev` and `mkdir dev/x.y.z`
+.. `cp ~/.m2/repository/org/apache/tinkerpop/gremlin-console/x.y.z/gremlin-console-x.y.z-distribution.zip* dev/x.y.z`
+.. `cp ~/.m2/repository/org/apache/tinkerpop/gremlin-server/x.y.z/gremlin-server-x.y.z-distribution.zip* dev/x.y.z`
+.. `cp ~/.m2/repository/org/apache/tinkerpop/tinkerpop/x.y.z/tinkerpop-x.y.z-source-release.zip* dev/x.y.z`
+.. `cd dev/x.y.z` and `for f in \*.zip*; do  mv "$f" "apache-$f"; done`
+.. `cd ..; svn add x.y.z/; svn ci -m "TinkerPop x.y.z release"`
+. Execute `bin/validate-distribution.sh` and any other relevant testing.
+. Perform JIRA administration tasks:
+.. "Release" the current version and set the "release date"
+.. If there is to be a follow on release in the current line of code, create that new version specifying the "start date"
+.. Migrate the "Affected Version" of all unresolved issues to the next lowest common denominator version - if version 3.0.1 released then all 3.0.0 issues should move forward to 3.0.1 as they now "affect" that latest release
+. Submit for `[VOTE]` at `dev@tinkerpop.incubator.apache.org` (see email template below)
+. *Wait for vote acceptance* (72 hours)
+
+Incubator Vote
+--------------
+
+A positive vote for a particular release from the Apache Incubator is required to move to the following phase.
+
+. Submit for `[VOTE]` at `general@incubator.apache.org` (see email template below)
+.. Include the vote tally: "Apache TinkerPop (http://tinkerpop.incubator.apache.org/) would like to release TinkerPop x.y.z. We had a dev@ VOTE which resulted in a tally of +1 (3), 0 (0), and -1 (0). We now present our artifacts for vote by Incubator."
+. *Wait for vote acceptance* (72 hours)
+
+Release & Promote
+-----------------
+
+. `mvn clean install -Djavadoc -Dmaven.test.skip=true; bin/process-docs.sh` - rebuild source and docs of tagged release
+. `mvn deploy -Papache-release -DcreateChecksum=true -Dmaven.test.skip=true`- deploy signed artifacts with checksums to Apache Nexus
+. Review and close the staging repository (Apache Nexus at link:https://repository.apache.org/[https://repository.apache.org/]) - check that versions are correct and that all artifacts are present
+. `svn co --depth empty https://dist.apache.org/repos/dist/dev/incubator/tinkerpop dev; svn up dev/x.y.z`
+. `svn co --depth empty https://dist.apache.org/repos/dist/release/incubator/tinkerpop release; mkdir release/x.y.z`
+. `ls dev/x.y.z/ | grep '\-\(distribution\|source\-release\)\.zip' | sed -e 's/\(^[^ ]\*\)-distribution\([^ ]*\)/cp dev\/x.y.z\/\0 release\/x.y.z\/\1-bin\2/' -e 's/\(^[^ ]\*\)-source-release\([^ ]*\)/cp dev\/x.y.z\/\0 release\/x.y.z\/\1-src\2/' | /bin/sh`
+. `cd release; svn add x.y.z/; svn ci -m "TinkerPop x.y.z release"`
+. Update homepage with references to latest distribution and to other internal links elsewhere on the page.
+. Wait for Apache Central to sync the jars and src (link:http://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/[http://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/]).
+. Announce release on `dev@`/`gremlin-users@` mailing lists and tweet from `@apachetinkerpop`
+
+Example `[VOTE]` email:
+
+```
+[VOTE] TinkerPop x.y.z Release
+
+Hello,
+
+The release artifacts can be found at this location:
+	https://dist.apache.org/repos/dist/dev/incubator/tinkerpop/x.y.z/
+
+The source distribution is provided by:
+	apache-tinkerpop-x.y.z-source-release.zip
+
+Two binary distributions are provided for user convenience:
+	apache-gremlin-console-x.y.z-distribution.zip
+	apache-gremlin-server-x.y.z-distribution.zip
+
+The online docs can be found here:
+	http://tinkerpop.incubator.apache.org/docs/x.y.z/ (user docs)
+	http://tinkerpop.incubator.apache.org/docs/x.y.z/upgrade.html (upgrade docs)
+	http://tinkerpop.incubator.apache.org/javadocs/x.y.z/core/ (core javadoc)
+	http://tinkerpop.incubator.apache.org/javadocs/x.y.z/full/ (full javadoc)
+
+The tag in Apache Git can be found here:
+	https://git-wip-us.apache.org/repos/asf?p=incubator-tinkerpop.git;...
+
+The release notes are available here:
+	https://github.com/apache/incubator-tinkerpop/blob/master/CHANGELOG.asciidoc#...
+
+The [VOTE] will be open for the next 72 hours --- closing <DayOfTheWeek> (<Month> <Day> <Year>) at <Time> <TimeZone>.
+
+My vote is +1.
+
+Thank you very much,
+<TinkerPop Committer Name>
+```
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/3a3fdf75/docs/src/developer.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/developer.asciidoc b/docs/src/developer.asciidoc
new file mode 100644
index 0000000..93db877
--- /dev/null
+++ b/docs/src/developer.asciidoc
@@ -0,0 +1,29 @@
+////
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at
+
+  http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed under the License is distributed on an "AS IS" BASIS,
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+See the License for the specific language governing permissions and
+limitations under the License.
+////
+image::apache-tinkerpop-logo.png[width=500]
+
+:toc-position: left
+
+Developer Documentation
+=======================
+
+This document contains information for TinkerPop developers, contributors, and community members. It focuses on
+technical information and other internal processes related to the project.
+
+include::developer-contributing.asciidoc[]
+
+include::developer-release.asciidoc[]
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/incubator-tinkerpop/blob/3a3fdf75/pom.xml
----------------------------------------------------------------------
diff --git a/pom.xml b/pom.xml
index 3280811..82fbb77 100644
--- a/pom.xml
+++ b/pom.xml
@@ -708,7 +708,7 @@ limitations under the License.
                                 </configuration>
                             </execution>
                             <execution>
-                                <id>asciidoc-to-upgrade</id>
+                                <id>asciidoc-to-upgrade-book</id>
                                 <phase>generate-resources</phase>
                                 <goals>
                                     <goal>process-asciidoc</goal>
@@ -734,6 +734,33 @@ limitations under the License.
                                     </attributes>
                                 </configuration>
                             </execution>
+                            <execution>
+                                <id>asciidoc-to-developer-book</id>
+                                <phase>generate-resources</phase>
+                                <goals>
+                                    <goal>process-asciidoc</goal>
+                                </goals>
+                                <configuration>
+                                    <sourceDirectory>${asciidoc.input.dir}</sourceDirectory>
+                                    <sourceDocumentName>developer.asciidoc</sourceDocumentName>
+                                    <outputDirectory>${htmlsingle.output.dir}</outputDirectory>
+                                    <backend>html5</backend>
+                                    <doctype>book</doctype>
+                                    <attributes>
+                                        <imagesdir>images</imagesdir>
+                                        <encoding>UTF-8</encoding>
+                                        <toc>true</toc>
+                                        <toclevels>3</toclevels>
+                                        <toc-position>left</toc-position>
+                                        <!--<iconsdir>images/icons</iconsdir>-->
+                                        <!-- AsciiDoctor CSS3-based theme configuration -->
+                                        <stylesdir>${asciidoctor.style.dir}</stylesdir>
+                                        <stylesheet>tinkerpop.css</stylesheet>
+                                        <source-highlighter>coderay</source-highlighter>
+                                        <basedir>${project.basedir}</basedir>
+                                    </attributes>
+                                </configuration>
+                            </execution>
                         </executions>
                     </plugin>
                 </plugins>


Mime
View raw message