apache tinkerpop logo


TinkerPop Future

This document offers a rough view at what features can be expected from future releases and catalogs proposals for changes that might be better written and understood in a document form as opposed to a dev list post.

This document is meant to change and restructure frequently and should serve more as a guide rather than directions set in stone. As this document represents a future look, the current version is always on the master branch and therefore the only one that need be maintained.


gremlin explorer old photoThis section provides some expectations as to what features might be provided in future major versions. It is not a guarantee of a feature landing in a particular version, but it yields some sense of what core developers have some focus on. The most up-to-date version of this document will always be in the git repository.

The sub-sections that follow only outline those release lines that expect to include significant new features. Other release lines may continue to be active with maintenance work and bug fixes, but won’t be listed here. The items listed in each release line represent unreleased changes only. Once an official release is made for a line, the roadmap items are removed with new items taking their place as they are planned. The release line is removed from the roadmap completely when it is no longer maintained.

3.7.x - Target 2023H1

The development of the 3.7.x release line is currently under way with a target release date for the initial release of the line of 23H1.

  • Add support for traversals as parameters for V(), is(), and has() (includes Traversal arguments to P)

  • Geospatial support for TinkerPop (DISCUSS Thread)

  • Add mid-traversal E() support (TINKERPOP-2798)

  • Allow properties on elements (as opposed to just references) for remote traversals

  • Add subgraph/tree structure in all GLVs

  • List functions (concat()/etc.)

  • Define semantics for query federation across Gremlin servers (depends on call() step)

  • Gremlin debug support

  • Date/Time manipulation functions (dateAdd(), dateDiff(), etc.)

  • Add string manipulation functions (split(), substring() etc.) (TINKERPOP-2672)

  • Case-insensitive search (TINKERPOP-2673)

  • Type conversion with cast() step

  • Mutation steps for clone() of an Element and for moveE() for edges.

  • Add a language element to merge Map objects more easily.


This section tracks and details future ideas. While the dev list is the primary place to talk about new ideas, complex topics can be initiated from and/or promoted to this space. While it is fine to include smaller bits of content directly in future/index.asciidoc, longer, more developed proposals and ideas would be better added as individual asciidoc files which would then be included as links to the GitHub repository where they will be viewable in a formatted state. In this way, this section is more just a list of links to proposals rather than an expansion of text. Proposals should be named according to this pattern "proposal-<name>-<number>" where the "name" is just a logical title to help identify the proposal and the "number" is the incremented proposal count.

The general structure of a proposal is fairly open but should include an initial "Status" section which would describe the current state of the proposal. A new proposal would likely hae a status like "Open for discussion". From there, the proposal should include something about the "motivation" for the change which describes a bit about what the issue is and why a change is needed. Finally, it should explain the details of the change itself.

At this stage, the proposal can then be submitted as a pull request for comment. As part of that pull request, the proposal should be added to the table below. Proposals always target the master branch.

The table below lists various proposals and their disposition. The Targets column identifies the release or releases to which the proposal applies and the Resolved column helps clarify the state of the proposal itself. Generally speaking, the proposal is "resolved" when the core tenants of its contents are established. For some proposals that might mean "fully implemented", but it might also mean "scheduled and scoped with open issues set aside". In that sense, the meaning is somewhat subjective. Consulting the "Status" section of the proposal itself will provide the complete story.

Proposal Description Targets Resolved

Proposal 1

Equality, Equivalence, Comparability and Orderability Semantics - Documents existing Gremlin semantics along with clarifications for ambiguous behaviors and recommendations for consistency.



Proposal 2

Gremlin Arrow Flight.



Proposal 3

Removing the Need for Closures/Lambda in Gremlin





This space is currently a bit of a scratchpad for ideas and changes that might not fit well into TinkerPop3 and therefore might be best left to TinkerPop4.

  • Transactions - Redesign the transaction model so that it is better suited for all graphs.

    • Ensure that TinkerPop has a native implementation for transactions in TinkerGraph so that all tests can run from it.

    • Ensure that there is no difference between remote and embedded transaction usage and that the API is less tangled than it is today.

  • Groovy - Reconsider all dependencies on Groovy throughout TinkerPop

    • Remove Groovy support from Gremlin Server which should be possible now that gremlin-language and call() are available.

    • Investigate options for using JShell as a replacement for groovysh in Gremlin Console.

    • Investigate options for removing ScriptEngine support in general, which would include support from gremlin-language.

4.x Branching Methodology

Development of 4.x occurs on the 4.0-dev branch. This branch was created as an orphan branch and therefore has no history tied to any other branch in the repo including master. As such, there is no need to merge/rebase 4.0-dev. When it comes time to promote 4.0-dev to master the procedure for doing so will be to:

  1. Create a 3.x-master branch from master

  2. Delete all content from master in one commit

  3. Rebase 4.0-dev on master

  4. Merge 4.0-dev to master and push

From this point 3.x development will occur on 3.x-master and 4.x development occurs on master (with the same version branching as we have now, e.g 3.3-dev, 4.1-dev, etc.) The 3.x-master branch changes will likely still merge to master, but will all merge as no-op changes.