anchor.diff:  .. `cp ~/.m2/repository/org/apache/tinkerpop/gremlin-console/xx.yy.zz/gremlin-console-xx.yy.zz-distribution.zip* dev/xx.yy.zz`
   .. `cp ~/.m2/repository/org/apache/tinkerpop/gremlin-server/xx.yy.zz/gremlin-server-xx.yy.zz-distribution.zip* dev/xx.yy.zz`
   .. `cp ~/.m2/repository/org/apache/tinkerpop/tinkerpop/xx.yy.zz/tinkerpop-xx.yy.zz-source-release.zip* dev/xx.yy.zz`
  -.. `rm -f dev/*.md5
  +.. `rm -f dev/*.md5`
   .. `cd dev/xx.yy.zz`
   .. pass:[<code>ls * | xargs -n1 -I {} echo "mv apache-tinkerpop-{} {}" | sed -e 's/distribution/bin/' -e 's/source-release/src/' -e 's/tinkerpop-tinkerpop/tinkerpop/' -e s'/^\(.*\) \(.*\) \(.*\)$/\1 \3 \2/' | /bin/bash</code>]
   .. `cd ..; svn add xx.yy.zz/; svn ci -m "TinkerPop xx.yy.zz release"`
   . Execute `bin/validate-distribution.sh` and any other relevant testing.
   . `git tag -a -m "TinkerPop xx.yy.zz release" xx.yy.zz` and `git push --tags`
  -. 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"
  -. Prepare Git administration tasks. Note that this work can be performed at the release manager's discretion. It may be wise to wait until a successful VOTE is eminent before reopening development. Apply the following steps as needed per release branch:
  -.. Make the appropriate branching changes as required by the release and bump the version to `SNAPSHOT` with
  -`mvn versions:set -DnewVersion=xx.yy.zz-SNAPSHOT -DgenerateBackupPoms=false`.
  -.. `pushd gremlin-console/bin; ln -fs ../target/apache-tinkerpop-gremlin-console-xx.yy.zz-SNAPSHOT-standalone/bin/gremlin.sh gremlin.sh; popd`
  -.. Update CHANGELOG and upgrade docs to have the appropriate headers for the next version.
  -.. `mvn clean install -DskipTests` - need to build first so that the right version of the console is used with `bin/publish-docs.sh`
  -.. `mvn deploy -DskipTests` - deploy the new `SNAPSHOT`
  -.. `bin/process-docs.sh` and validate the generated `SNAPSHOT` documentation locally and then `bin/publish-docs.sh <username>`
  -.. Commit and push the `SNAPSHOT` changes to git
  -.. Send email to advise that code freeze is lifted.
  -.. Generate a list of dead branches that will be automatically deleted and post them as a DISCUSS thread for review, then once consensus is reached removed those branches.
   . Submit for `[VOTE]` at `dev@tinkerpop.apache.org` (see email template below)
   . *Wait for vote acceptance* (72 hours)
   
  
positive.code: . Wait for Apache Sonatype to sync the artifacts to Maven Central at (link:http://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/[http://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/]).
  . Report the release through link:https://reporter.apache.org/addrelease.html?tinkerpop[reporter.apache.org] (an email reminder should arrive shortly following the svn command above to do the release)
  . Wait for zip distributions to to sync to the Apache mirrors (i.e ensure the download links work from a mirror).
  . Update home page site with references to latest distribution - specifically:
  .. Update the `template/header-footer.html`.
  .. Update `index.html`.
  .. Update link:http://tinkerpop.apache.org/downloads.html[Downloads] page, when moving "Current Releases" to "Archived
  Releases" recall that the hyperlink must change to point to version in the link:https://archive.apache.org/dist/tinkerpop/[Apache Archives].
  . Execute `bin/update-current-docs.sh` to migrate to the latest documentation set for `/current`.
  . This step should only occur after the website is updated and all links are working. If there are releases present in
  SVN that represents lines of code that are no longer under development, then remove those releases. In other words,
  
negative.code: code is still under potential development, it may stay.
  . Announce release on `dev@`/`gremlin-users@` mailing lists and tweet from `@apachetinkerpop`
  
  == Post-release Tasks
  
  A number of administration tasks should be taken care of after release is public. Some of these items can be performed
  during the VOTE period at the release manager's discretion, though it may be wise to wait until a successful VOTE is
  eminent before reopening development. When there are multiple release managers, it's best to coordinate these tasks
  as one individual may simply just handle them all.
  
  . 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"
  . Prepare Git administration tasks. Apply the following steps as needed per release branch:
  .. Make the appropriate branching changes as required by the release and bump the version to `SNAPSHOT` with
  `mvn versions:set -DnewVersion=xx.yy.zz-SNAPSHOT -DgenerateBackupPoms=false`.
  .. `pushd gremlin-console/bin; ln -fs ../target/apache-tinkerpop-gremlin-console-xx.yy.zz-SNAPSHOT-standalone/bin/gremlin.sh gremlin.sh; popd`
  .. Update CHANGELOG and upgrade docs to have the appropriate headers for the next version.
  .. `mvn clean install -DskipTests` - need to build first so that the right version of the console is used with `bin/publish-docs.sh`
  .. `mvn deploy -DskipTests` - deploy the new `SNAPSHOT`
  .. `bin/process-docs.sh` and validate the generated `SNAPSHOT` documentation locally and then `bin/publish-docs.sh <username>`
  .. Commit and push the `SNAPSHOT` changes to git
  . Send email to advise that code freeze is lifted.
  . Generate a list of dead branches that will be automatically deleted and post them as a DISCUSS thread for review,
  then once consensus is reached removed those branches.
  
  == Email Templates
  
  === Release VOTE
  