TinkerPop has a user mailing list and a developer mailing list. As a committer, it is a good idea to join both.

It would also be helpful to join the public 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.

Occasionally, online meetings via video conference are held. These meetings are schedule via the dev mailing list about a week before they are to occur to find a day and time that is available for those interested in attending. On the day of the meeting, the meeting organizer will create a Google Hangout (or similar video conferencing link) to post to the TinkerPop room in HipChat. At that point, all who are interested can attend. Meeting minutes should be taken and added to the Meetings section of this document using the pattern already established.

There is a two-pronged approach to maintaining the change log and preparing the release notes.

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.

The "master" branch is used for the main line of development and release branches are constructed as needed for ongoing maintenance work. If new to the project or are returning to it after some time away, it may be good to send an email to the developer mailing list (or ask on HipChat) to find out what the current operating branches are.

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 are used for milestones, release candidates, and approved releases. Please refrain from creating arbitrary tags, as they produce permanent clutter.

TinkerPop uses Apache JIRA as its 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:

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.

TinkerPop uses both Travis and AppVeyor for CI services. Travis validates builds on Ubuntu, while AppVeyor validates builds on Windows. The build statuses can be found here:

Note that the CI process does not run integration tests or include Neo4j-related tests as those tests would likely exceed the allowable times for builds on these servers.

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:

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.

TinkerPop has a wide variety of test types that help validate its internal code as well as external provider code. There are "unit tests" and "integration tests". Unit tests execute on standard runs of mvn clean install. These tests tend to run quickly and provide a reasonable level of coverage and confidence in the code base. Integration tests are disabled by default and must be explicitly turned on with a special build property by adding -DskipIntegrationTests=false to the mvn execution. Integration tests run slower and may require external components to be running when they are executed. They are "marked" as separate from unit tests by inclusion of the suffix "IntegrateTest".

Here are some other points to consider when developing tests:

Code modifications must go through a 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.

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 at the types of commits that do not require a review.

When the committer chooses CTR, it is considered good form to include something in the commit message that explains that CTR was invoked and the reason for doing so. For example, "Invoking CTR as this change encompasses minor adjustments to text formatting."

There are many dependencies on other open source libraries in TinkerPop modules. When adding dependencies or altering the version of a dependency, developers must consider the implications that may apply to the TinkerPop LICENSE and NOTICE files. There are two implications to consider:

Understanding these implications is important for insuring that TinkerPop stays compliant with the Apache 2 license that it releases under.

Regarding the first item, refer to the Apache Legal for a list of approved licenses that are compatible with the Apache 2 license.

The second item requires a bit more effort to follow. The Apache website offers a how-to guide on the approach to maintaining appropriate LICENSE and NOTICE files, but this guide is designed to offer some more specific guidance as it pertains to TinkerPop and its distribution.

To get started, TinkerPop has both "source" and "binary" LICENSE/NOTICE files:

The documentation for TinkerPop is stored in the git repository in docs/src/ and are then split into several subdirectories, each representing a "book" (or its own publishable body of work). If a new AsciiDoc file is added to a book, then it should also be included in the index.asciidoc file for that book, otherwise the preprocessor will ignore it. Likewise, if a whole new book (subdirectory) is added, it must include an index.asciidoc file to be recognized by the AsciiDoc preprocessor.

Adding a book also requires a change to the root pom.xml file. Find the "asciidoc" Maven profile and add a new <execution> to the asciidoctor-maven-plugin configuration. For each book in docs/src/, there should be a related <execution> that generates the HTML from the AsciiDoc. Follows the patterns already established by the existing <execution> entries, paying special attention to the pathing of the <sourceDirectory>, <outputDirectory> and <imagesdir>. Note that the <outputDirectory> represents where the book will exist when uploaded to the server and should preserve the directory structure in git as referenced in <sourceDirectory>.

Please see the Building and Testing section for more information on how to generate the documentation.

TinkerPop uses SLF4j for logging and typically leans back on Log4j as the implementation. Configuring log outputs for debugging purposes within tests can be altered by editing the log4j-test.properties file in each module’s test resources. That file gets copied to the target/test-classes on build and surefire and failsafe plugins in maven are then configured to point at that area of the file system for those configuration files. The properties files can be edited to fine tune control of the log output, but generally speaking the current configuration is likely best for everyone’s general purposes, so if changes are made please revert them prior to commit.

If the above email template is used for the "Incubator Vote", then it should include the following just after the "release notes":

where this link should point to the result of the VOTE.

Subject: TinkerPop xx.yy.zz Released: [name of release line]

Hello,

TinkerPop xx.yy.zz has just been released. You can find all the links and goodies on our homepage at http://tinkerpop.apache.org. However, if that is just one click too many, then the respective links are below.

The release artifacts can be found at this location: https://www.apache.org/dyn/closer.lua/incubator/tinkerpop/xx.yy.zz/apache-gremlin-console-xx.yy.zz-bin.zip https://www.apache.org/dyn/closer.lua/incubator/tinkerpop/xx.yy.zz/apache-gremlin-server-xx.yy.zz-bin.zip

The online docs can be found here (note that the URL structure has changed with this release): http://tinkerpop.apache.org/docs/xx.yy.zz/reference/ (user docs) http://tinkerpop.apache.org/docs/xx.yy.zz/upgrade.html#XXXXXXXXXXXXXXXXXX (upgrade docs) http://tinkerpop.apache.org/docs/xx.yy.zz/tutorials/the-gremlin-console/ (gremlin console tutorial) [NEW!] http://tinkerpop.apache.org/javadocs/xx.yy.zz/core/ (core javadoc) http://tinkerpop.apache.org/javadocs/xx.yy.zz/full/ (full javadoc)

The release notes are available here: https://github.com/apache/incubator-tinkerpop/blob/xx.yy.zz/CHANGELOG.asciidoc#XXXXXXXXXXXXXXXXXX

The Central Maven repo has sync’d as well: https://repo1.maven.org/maven2/org/apache/tinkerpop/tinkerpop/xx.yy.zz/