docs/src/dev/future/index.asciidoc - tinkerpop - Git at Google

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