Hi Andrii - now that 3.8.x is out, I think most new features will be targeted for 4.x with particular focus on addressing the gaps that currently exist there (like transactions). It's not clear how long that will take as of yet. While most effort will be on 4.x, if you think that you have more contributions like this change with call/antlr, I think that we could talk about doing a 3.9.x if that is helpful to you.
Roughly speaking, I think 3.9.x changes would merge to 4.x and would need to maintain Gremlin semantics established in 3.8.x and avoid any breaking changes to drivers. Additive features would be less of an issue (like call/antlr) but like all features, we'd take each one on a case by case basis to decide what release line they are best for. Do you feel like you would like a 3.9.0? Also, happy to hear from other contributors on this topic. We hadn't planned a 3.9.0, so please consider this an open discussion. On Wed, Jan 21, 2026 at 2:14 AM Andrii Lomakin <[email protected]> wrote: > Good day. > > I suppose I need to add more context. > We cannot use 4.0 if it will be released with the current feature set (for > reasons I mentioned in other topics), so all development we do is on top of > the 3.8 release branch. > > I think it would be beneficial to backport our changes to 3.8 if possible, > but given the release policy situation, I am not sure it is. > Would be glad if the TinkerPop team could share any ideas with us. > > Also, I invite anyone to join our Zulip chat to participate in discussions > about our early-stage implementation of GQL. > We, of course, will contact you once it is ready to refine the spec of the > match step anyway. > > > On Tue, Jan 20, 2026 at 4:11 PM Andrii Lomakin < > [email protected]> wrote: > >> No, we based our changes on 3.8-dev. >> >> >Out of curiosity, you mentioned this update as a "need" - is there >> something specific in the newer version that is required for the >> implementation? >> >> We had problems generating visitors for the updated grammar. >> >> On Tue, Jan 20, 2026 at 1:24 PM Stephen Mallette <[email protected]> >> wrote: >> >>> I assume you're targeting the master branch with this change. If so, >>> then I don't think there is a problem with going to a newer version. >>> >>> Out of curiosity, you mentioned this update as a "need" - is there >>> something specific in the newer version that is required for the >>> implementation? >>> >>> On Tue, Jan 20, 2026 at 4:47 AM Andrii Lomakin via dev < >>> [email protected]> wrote: >>> >>>> Good day, TP team. >>>> To implement this feature, we need to update ANTLR to the latest >>>> version. >>>> Do you have any objections ? >>>> If not, we will provide PR soon. >>>> >>>> On Mon, Jan 19, 2026 at 4:39 PM Andrii Lomakin < >>>> [email protected]> >>>> wrote: >>>> >>>> > Good day. >>>> > As part of our efforts to implement GQL, we started working on this >>>> issue: >>>> > >>>> https://youtrack.jetbrains.com/issue/YTDB-505/Implement-the-ability-to-convert-non-standard-method-calls-into-the-registered-service-calls >>>> > . >>>> > Sandra will provide PR once it is ready. >>>> > >>>> > On Fri, Nov 21, 2025 at 1:52 PM Andrii Lomakin < >>>> [email protected]> >>>> > wrote: >>>> > >>>> >> Good day, >>>> >> >>>> >> Following up on Ken's point about the discrepancy between scripts and >>>> >> traversals, I have an alternative idea that could resolve this >>>> issue, in >>>> >> addition to the proposal I mentioned in the other thread. >>>> >> >>>> >> The proposal is to introduce a mechanism that allows a user to >>>> create a >>>> >> part of a graph traversal in script form, such as: >>>> >> `g.gScript("V(id).hasName()")` >>>> >> >>>> >> The responsibility for handling this script would then fall to the >>>> GLV, >>>> >> which would have two primary options: >>>> >> >>>> >> 1. Pass the script string to the server for parsing. >>>> >> 2. Convert the script to local steps before passing the steps to the >>>> >> server >>>> >> (my preferred approach). >>>> >> >>>> >> For the latter, a more advanced option could be available for vendors >>>> >> working on Java: they could use a ClassLoader to dynamically >>>> download the >>>> >> vendor’s JAR from Gremlin Server into the client’s classpath. If this >>>> >> approach were adopted, the ClassLoading mechanism would need to >>>> become a >>>> >> formal part of the Gremlin Server protocol, as the vendor does not >>>> control >>>> >> the client at this stage. >>>> >> >>>> >> This dynamic approach could also address issues related to custom >>>> >> serializers, though it would likely only be applicable to Java and >>>> other >>>> >> dynamic languages, and not to languages like Go. However, for >>>> drivers such >>>> >> as .NET, JavaScript, and Python, a similar level of abstraction could >>>> >> potentially be implemented within the protocol to achieve the same >>>> result. >>>> >> >>>> >> Best regards, >>>> >> >>>> >> Andrii Lomakin >>>> >> YouTrackDB development lead. >>>> >> >>>> >> On Thu, Nov 20, 2025 at 7:09 PM Ken Hu <[email protected]> wrote: >>>> >> >>>> >> > I think the initial challenge that I pointed out still exists, >>>> which is, >>>> >> > scripts and traversals won't have the same capabilities >>>> out-of-the-box. >>>> >> > Again, I'm in favor of this proposal and would like to see it >>>> >> implemented. >>>> >> > All I'm trying to say is, can we also come up with an equivalent >>>> >> proposal >>>> >> > for remote traversals. >>>> >> > >>>> >> > On Thu, Nov 20, 2025 at 5:18 AM Stephen Mallette < >>>> [email protected]> >>>> >> > wrote: >>>> >> > >>>> >> > > I think Ken provides a good point to consider about external >>>> >> > dependencies. >>>> >> > > Andrii, for further context, traditionally, we've found that >>>> users >>>> >> tend >>>> >> > to >>>> >> > > expect TinkerPop to just work with any provider. They want to >>>> >> download a >>>> >> > > driver in their programming language and get to work writing >>>> their >>>> >> > > applications. What they have found is that in some cases it's not >>>> >> quite >>>> >> > as >>>> >> > > easy as that. For example, Ken alludes to the serializers where >>>> users >>>> >> > often >>>> >> > > learn in a very hard way that if they use JanusGraph they need >>>> to add >>>> >> in >>>> >> > a >>>> >> > > customer serializer for certain operations to work. We've made >>>> it a >>>> >> goal >>>> >> > > for TinkerPop 4.x to not require TinkerPop drivers to have those >>>> >> kinds of >>>> >> > > dependencies that complicate the user experience. >>>> >> > > >>>> >> > > I think in this case, a DSL offers as a separate dependency by a >>>> >> provider >>>> >> > > doesn't exactly conflict with this goal because the DSL simply >>>> >> enhances >>>> >> > the >>>> >> > > experience the user has, but doesn't require it for standard >>>> TinkerPop >>>> >> > > features to work. A user could even fallback to raw call() steps >>>> >> without >>>> >> > > using the DSL at all and still access the same functionality. >>>> The DSL >>>> >> is >>>> >> > > merely a (highly useful) convenience in this case. Ken, do you >>>> think >>>> >> that >>>> >> > > perspective helps align this idea to the goal of trying to keep >>>> things >>>> >> > > working out-of-the-box? >>>> >> > > >>>> >> > > On Wed, Nov 19, 2025 at 12:25 PM Ken Hu <[email protected]> >>>> wrote: >>>> >> > > >>>> >> > > > That's not necessarily the case. If you think that there are >>>> users >>>> >> that >>>> >> > > > don't mind doing that then it is fine. I've just seen >>>> questions from >>>> >> > > users >>>> >> > > > in the past about how to make the GLV work with specific >>>> providers >>>> >> > > because >>>> >> > > > they didn't realize they needed additional dependencies and >>>> where to >>>> >> > find >>>> >> > > > those dependencies. I'm just wondering how and if it impacts >>>> user >>>> >> > > > experience. >>>> >> > > > >>>> >> > > > On Wed, Nov 19, 2025 at 9:18 AM Andrii Lomakin >>>> >> > > > <[email protected]> wrote: >>>> >> > > > >>>> >> > > > > Is my understanding correct that you don't support this >>>> change if >>>> >> it >>>> >> > > > > requires additional dependencies from vendor ? >>>> >> > > > > >>>> >> > > > > On Wed, 19 Nov 2025, 17:51 Ken Hu, <[email protected]> >>>> wrote: >>>> >> > > > > >>>> >> > > > > > I don't think this proposal requires custom serializers. I >>>> was >>>> >> > trying >>>> >> > > > to >>>> >> > > > > > say that based on my understanding of this proposal, there >>>> may >>>> >> be >>>> >> > an >>>> >> > > > > issue >>>> >> > > > > > that is similar to the one we see with custom serializers. >>>> That >>>> >> > issue >>>> >> > > > > > being, how is this custom provider DSL packaged with the >>>> GLV so >>>> >> > that >>>> >> > > > > users >>>> >> > > > > > can gain access to those additional methods in remote >>>> traversals >>>> >> > > > without >>>> >> > > > > > needing to add an additional dependency from the provider >>>> >> itself? >>>> >> > > > > > >>>> >> > > > > > On Tue, Nov 18, 2025 at 10:46 PM Andrii Lomakin >>>> >> > > > > > <[email protected]> wrote: >>>> >> > > > > > >>>> >> > > > > > > Good day, Ken. >>>> >> > > > > > > >>>> >> > > > > > > Could you clarify why you think that this proposal >>>> requires >>>> >> > custom >>>> >> > > > > > > serializers? >>>> >> > > > > > > >>>> >> > > > > > > On Tue, Nov 18, 2025 at 11:39 PM Ken Hu < >>>> [email protected]> >>>> >> > > wrote: >>>> >> > > > > > > >>>> >> > > > > > > > I guess I'm still not certain how this DSL would get >>>> >> packaged >>>> >> > > with >>>> >> > > > > the >>>> >> > > > > > > > GLVs. One of the situations I'm trying to avoid is the >>>> one >>>> >> we >>>> >> > > face >>>> >> > > > > with >>>> >> > > > > > > > custom type serialization. Providers with custom types >>>> >> > generally >>>> >> > > > need >>>> >> > > > > > to >>>> >> > > > > > > > package their serializers as a separate module which >>>> users >>>> >> of >>>> >> > the >>>> >> > > > GLV >>>> >> > > > > > > will >>>> >> > > > > > > > then add as a dependency. This creates confusion for >>>> users >>>> >> as >>>> >> > > they >>>> >> > > > > > aren't >>>> >> > > > > > > > able to just use the GLV by itself. They need to grab >>>> an >>>> >> > > additional >>>> >> > > > > > > > dependency from their provider as well. It isn't always >>>> >> clear >>>> >> > to >>>> >> > > > them >>>> >> > > > > > > that >>>> >> > > > > > > > this is the case. >>>> >> > > > > > > > >>>> >> > > > > > > > On Fri, Nov 14, 2025 at 10:04 AM Andrii Lomakin < >>>> >> > > > > > > [email protected]> >>>> >> > > > > > > > wrote: >>>> >> > > > > > > > >>>> >> > > > > > > > > Hi Ken, >>>> >> > > > > > > > > >>>> >> > > > > > > > > To clarify, the functionality you mentioned regarding >>>> >> remote >>>> >> > > > > > Traversal >>>> >> > > > > > > > > from a GLV is already fully supported by TinkerPop. >>>> >> > > > > > > > > >>>> >> > > > > > > > > While there are some current issues with the DSL >>>> >> processor, >>>> >> > > they >>>> >> > > > > are >>>> >> > > > > > > > > implementation details that we intend to resolve >>>> through >>>> >> the >>>> >> > > > > > > > > contribution of our version of an annotation >>>> processor, >>>> >> which >>>> >> > > > will >>>> >> > > > > > not >>>> >> > > > > > > > > require any changes to the TinkerPop documentation. >>>> >> > > > > > > > > >>>> >> > > > > > > > > For a concrete example of our implementation of DSL, >>>> >> please >>>> >> > see >>>> >> > > > the >>>> >> > > > > > > > > following: >>>> >> > > > > > > > > >>>> >> > > > > > > > > >>>> >> > > > > > > > >>>> >> > > > > > > >>>> >> > > > > > >>>> >> > > > > >>>> >> > > > >>>> >> > > >>>> >> > >>>> >> >>>> https://github.com/JetBrains/youtrackdb/blob/develop/core/src/main/java/com/jetbrains/youtrackdb/api/gremlin/YTDBGraphTraversalDSL.java >>>> >> > > > > > > > > ( >>>> >> > > > > > > > > >>>> >> > > > > > > > >>>> >> > > > > > > >>>> >> > > > > > >>>> >> > > > > >>>> >> > > > >>>> >> > > >>>> >> > >>>> >> >>>> https://github.com/JetBrains/youtrackdb/blob/develop/core/src/main/java/com/jetbrains/youtrackdb/api/gremlin/YTDBGraphTraversalDSL.java >>>> >> > > > > > > > > ) >>>> >> > > > > > > > > >>>> >> > > > > > > > > Andrii Lomakin, >>>> >> > > > > > > > > YouTrackDB development lead. >>>> >> > > > > > > > > >>>> >> > > > > > > > > On Fri, Nov 14, 2025 at 6:59 PM Andrii Lomakin < >>>> >> > > > > > > [email protected] >>>> >> > > > > > > > > >>>> >> > > > > > > > > wrote: >>>> >> > > > > > > > > > >>>> >> > > > > > > > > > Hi Ken, >>>> >> > > > > > > > > > >>>> >> > > > > > > > > > The scenario you described regarding remote >>>> Traversal >>>> >> from >>>> >> > a >>>> >> > > > GLV >>>> >> > > > > is >>>> >> > > > > > > > > > automatically handled. >>>> >> > > > > > > > > > >>>> >> > > > > > > > > > The GLV would provide code similar to the existing >>>> >> > > > implementation >>>> >> > > > > > we >>>> >> > > > > > > > > > already have, which can be found here: >>>> >> > > > > > > > > > >>>> >> > > > > > > > > >>>> >> > > > > > > > >>>> >> > > > > > > >>>> >> > > > > > >>>> >> > > > > >>>> >> > > > >>>> >> > > >>>> >> > >>>> >> >>>> https://github.com/JetBrains/youtrackdb/blob/develop/core/src/main/java/com/jetbrains/youtrackdb/api/gremlin/YTDBGraphTraversalSourceDSL.java#L95 >>>> >> > > > > > > > > > >>>> >> > > > > > > > > > Andrii Lomakin, >>>> >> > > > > > > > > > YouTrackDB development lead. >>>> >> > > > > > > > > > >>>> >> > > > > > > > > > On Fri, Nov 14, 2025 at 6:40 PM Ken Hu < >>>> >> [email protected] >>>> >> > > >>>> >> > > > > wrote: >>>> >> > > > > > > > > > > >>>> >> > > > > > > > > > > What does this mean if someone tries to send a >>>> remote >>>> >> > > > Traversal >>>> >> > > > > > > from >>>> >> > > > > > > > a >>>> >> > > > > > > > > GLV? >>>> >> > > > > > > > > > > I'm guessing that is what makes "1. Providing >>>> DSL that >>>> >> > does >>>> >> > > > the >>>> >> > > > > > > same >>>> >> > > > > > > > > call" >>>> >> > > > > > > > > > > necessary. I think that scripts and traversals >>>> need to >>>> >> > have >>>> >> > > > the >>>> >> > > > > > > same >>>> >> > > > > > > > > > > capabilities "out of the box" when using the >>>> GLVs. So >>>> >> > > while I >>>> >> > > > > > think >>>> >> > > > > > > > > this is >>>> >> > > > > > > > > > > a good idea, I would also like to see a proposal >>>> on >>>> >> what >>>> >> > > can >>>> >> > > > be >>>> >> > > > > > > done >>>> >> > > > > > > > > for >>>> >> > > > > > > > > > > remote Traversals. >>>> >> > > > > > > > > > > >>>> >> > > > > > > > > > > On Thu, Nov 6, 2025 at 9:47 AM Andrea Child >>>> >> > > > > > > > > > > <[email protected]> wrote: >>>> >> > > > > > > > > > > >>>> >> > > > > > > > > > > > Hi Andrii, >>>> >> > > > > > > > > > > > >>>> >> > > > > > > > > > > > I like your idea as it would improve >>>> readability of >>>> >> > > > > traversals >>>> >> > > > > > to >>>> >> > > > > > > > be >>>> >> > > > > > > > > able >>>> >> > > > > > > > > > > > to reference the service directly in the >>>> grammar >>>> >> > instead >>>> >> > > of >>>> >> > > > > via >>>> >> > > > > > > the >>>> >> > > > > > > > > call >>>> >> > > > > > > > > > > > step. Looking forward to the contribution! >>>> >> > > > > > > > > > > > >>>> >> > > > > > > > > > > > Andrea >>>> >> > > > > > > > > > > > >>>> >> > > > > > > > > > > > From: Andrii Lomakin < >>>> [email protected] >>>> >> > > > .INVALID> >>>> >> > > > > > > > > > > > Date: Wednesday, November 5, 2025 at 8:15 AM >>>> >> > > > > > > > > > > > To: [email protected] < >>>> >> [email protected] >>>> >> > > >>>> >> > > > > > > > > > > > Subject: Proposal: Intorduction of equalence >>>> between >>>> >> > > > > > > > > call(serviceName, >>>> >> > > > > > > > > > > > args:List) and method call in scripts >>>> >> > > > > > > > > > > > >>>> >> > > > > > > > > > > > Good day, colleagues. >>>> >> > > > > > > > > > > > >>>> >> > > > > > > > > > > > I would like to propose an approach to >>>> enhancing the >>>> >> > > > > > > extensibility >>>> >> > > > > > > > > of the >>>> >> > > > > > > > > > > > Gremlin script, which, although it does not >>>> solve >>>> >> all >>>> >> > > > > problems, >>>> >> > > > > > > > will >>>> >> > > > > > > > > make >>>> >> > > > > > > > > > > > many Gremlin extensions feel native. >>>> >> > > > > > > > > > > > The Idea, as you may have already guessed from >>>> the >>>> >> > title, >>>> >> > > > is >>>> >> > > > > > > > simple: >>>> >> > > > > > > > > if a >>>> >> > > > > > > > > > > > service is registered in TinkerPop to treat it >>>> as a >>>> >> > > method >>>> >> > > > > call >>>> >> > > > > > > > with >>>> >> > > > > > > > > > > > parameters, such as args: List<Object> as an >>>> >> argument. >>>> >> > > > > > > > > > > > >>>> >> > > > > > > > > > > > So call like: g.schemClass("User") will be >>>> >> translated >>>> >> > to >>>> >> > > > > > > > > > > > g.call("schemaClass", "args" : ["User]) >>>> >> > > > > > > > > > > > >>>> >> > > > > > > > > > > > In such a case, providers will extend Gremlin >>>> >> twofold: >>>> >> > > > > > > > > > > > 1. Providing DSL that does the same call. >>>> >> > > > > > > > > > > > 2. Registering related service. >>>> >> > > > > > > > > > > > >>>> >> > > > > > > > > > > > If you agree with this proposal, I would be >>>> glad to >>>> >> > > > > contribute >>>> >> > > > > > > it, >>>> >> > > > > > > > > as I >>>> >> > > > > > > > > > > > mentioned, it does not solve all issues, such >>>> as the >>>> >> > > usage >>>> >> > > > of >>>> >> > > > > > > > custom >>>> >> > > > > > > > > > > > predicates, but I am under the impression that >>>> it >>>> >> can >>>> >> > be >>>> >> > > > > > extended >>>> >> > > > > > > > to >>>> >> > > > > > > > > that >>>> >> > > > > > > > > > > > case too in the future. >>>> >> > > > > > > > > > > > >>>> >> > > > > > > > > >>>> >> > > > > > > > >>>> >> > > > > > > >>>> >> > > > > > >>>> >> > > > > >>>> >> > > > >>>> >> > > >>>> >> > >>>> >> >>>> > >>>> > >>>> > -- >>>> > Andrii Lomakin >>>> > YouTrackDB development lead >>>> > >>>> >>>> >>>> -- >>>> Andrii Lomakin >>>> YouTrackDB development lead >>>> >>> >> >> -- >> Andrii Lomakin >> YouTrackDB development lead >> > > > -- > Andrii Lomakin > YouTrackDB development lead >
