////
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.
////

:docinfo: shared
:docinfodir: ../../
:toc-position: left

image::apache-tinkerpop-logo.png[width=500,link="https://tinkerpop.apache.org"]

*x.y.z*

= 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.

[[roadmap]]
= Roadmap

image:gremlin-explorer-old-photo.png[width=250,float=left]This section provides some expectations as to what features
might be provided in future link:https://tinkerpop.apache.org/docs/x.y.z/dev/developer/#_versioning[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
link:https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/index.asciidoc[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 (link:++https://lists.apache.org/list?dev@tinkerpop.apache.org:2021-7:DISCUSS%20geo-spatial++[DISCUSS Thread])
* Add mid-traversal `E()` support (link:https://issues.apache.org/jira/browse/TINKERPOP-2798[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.) (link:https://issues.apache.org/jira/browse/TINKERPOP-2672[TINKERPOP-2672])
* Case-insensitive search (link:https://issues.apache.org/jira/browse/TINKERPOP-2673[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.

= Proposals

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.

[width="100%",cols="3,10,2,^1",options="header"]
|=========================================================
|Proposal |Description |Targets |Resolved
|link:https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/proposal-equality-1.asciidoc[Proposal 1] |Equality, Equivalence, Comparability and Orderability Semantics - Documents existing Gremlin semantics along with clarifications for ambiguous behaviors and recommendations for consistency. |3.6.0 |N
|link:https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/proposal-arrow-flight-2[Proposal 2] |Gremlin Arrow Flight. |4.0.0 |N
|link:https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/proposal-3-remove-closures[Proposal 3] |Removing the Need for Closures/Lambda in Gremlin |3.7.0 |N
|=========================================================

= Appendix

== TinkerPop4

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`
1. Delete all content from `master` in one commit
1. Rebase `4.0-dev` on `master`
1. 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.
