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.
This 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 22Q4
Development has not yet started on the 3.7.x release line with a targeted release date for the initial release of the line of 22H2.
Add support for traversals as parameters for
Geospatial support for TinkerPop (DISCUSS Thread)
Allow properties on elements (as opposed to just references) for remote traversals
Add subgraph/tree structure in all GLVs
List functions (
Define semantics for query federation across Gremlin servers (depends on
Gremlin debug support
Date/Time manipulation functions (
Add string manipulation functions (
Case-insensitive search (TINKERPOP-2673)
Type conversion with
Mutation steps for
Add a language element to merge
Mapobjects 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
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
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.
Equality, Equivalence, Comparability and Orderability Semantics - Documents existing Gremlin semantics along with clarifications for ambiguous behaviors and recommendations for consistency.
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
Investigate options for using JShell as a replacement for
groovyshin Gremlin Console.
Investigate options for removing
ScriptEnginesupport in general, which would include support from
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
it comes time to promote
master the procedure for doing so will be to:
Delete all content from
masterin one commit
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
4.1-dev, etc.) The
3.x-master branch changes will likely still merge to
master, but will all merge as no-op changes.