This could be something we try to address some day in TinkerPop 4.x. It really shouldn't be handled by serialization versions, but it's also not as simple as a version field. Gremlin is a little different than the standard query language because the language is bound to the API which is versioned by a release. In an extreme crazy example, let's say that in 3.4.0 we had:
g.V().out() and for some reason in 3.5.0 we decided the Gremlin to do that should be: g.V().goOuty() We would deprecate out() and add goOuty() in 3.5.0. Then in 3.6.0 we would probably remove out() as a method from the API. So, now you try to connect to the 3.6.0 server with a 3.4.0 client and try to use out() because that's what the API allows and it won't work and no version field will help fix that because 3.6.0 won't have any knowledge of what out() means anymore as it has been removed from the API. I have given some thought to this general problem and I think the answer might lie in first decoupling the definition of the Gremlin language from the Gremlin VM within which it is executed. If there could somehow then be different VMs for each Gremlin version then you host multiple Gremlin versions within the same server. There's probably more to it than that, but I feel like that's where the starting point is. Again, not something we can likely solve along the 3.x line, but I will make a note to add this as a point to our 4.x dev/idea doc. On Sat, Apr 28, 2018 at 12:21 AM, divijvaidy...@gmail.com < divijvaidy...@gmail.com> wrote: > Hi all, > > I would like to understand the thoughts of the community and future > direction of development for versioning of Gremlin. > > Ideally, if a server supports multiple major versions of TP (let’s say TP3 > & TP4), the client (GLV) should have the capability to issue a query > pertaining to different versions. It could probably be achieved by using > different serialization format for different version but IMO, query > language should not be coupled with serialziation formats. A better way to > achieve it would be to introduce version field in the byte code message > itself. > > What do you think? >
