| //// |
| 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 |Y |
| |link:https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/proposal-arrow-flight-2[Proposal 2] |Gremlin Arrow Flight. |Future |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 |Y |
| |link:https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/proposal-transaction-4[Proposal 4] |TinkerGraph Transaction Support |3.7.0 |Y |
| |========================================================= |
| |
| = 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. |