Gremlin Snippets are typically short and fun dissections of some aspect of the Gremlin language. For a full list of all steps in the Gremlin language see the Reference Documentation of Apache TinkerPop™. This snippet is based on Gremlin 3.8.0. Please consider bringing any discussion or questions about this snippet to Discord or the Gremlin Users Mailing List.


Apache TinkerPop recently announced the joint releases of 3.7.5 and 3.8.0. I think that makes the total number of releases of 3.x under the Apache Software Foundation to be around 75 since 2015. If you follow TinkerPop then you know that the versioning scheme has been such that we allow breaking changes along minor versions and that the major version is a bit more symbolic than a sticking point of semantic versioning. So, while it seems as though TinkerPop has largely just been in a maintenance mode for 3.x for a decade, there’s actually been a great many new features and improvements that have landed along the way in various releases.

  • The 3.5.x line, “The Sleeping Gremlin: No. 18 Entr’acte Symphonique”, introduced remote transactions with g.tx() and gremlin-go.
  • The 3.6.x line, “Tinkerheart”, added mergeV and mergeE for upsert patterns, which drastically simplified Gremlin traversals and made the hard part of loading data more approachable.
  • The 3.7.x line, “Gremfir Master of the Pan Flute”, focused on adding Gremlin syntax offering primitive operations around manipulation of strings, dates, and lists, creating the largest expansion of the Gremlin language since the 3.x line began. It also introduced basic transactions to TinkerGraph and made Gremlin Language Variants more first class citizens by offering a way to return properties on elements.

The 3.8.0, “Grix Greven”, release has a slightly different story. In a sense, it was not contemplated to be as big as it came to be. Version 4.0.0 was on the horizon as a large breaking change, where TinkerPop would add major new features but, also address many inconsistencies and problems that could only be made in a version change where major incompatibilities could be taken. In the midst of that work, 4.0.0 was feeling like a cliff with a steep drop-off given all that was planned. To try to lessen that impact for users, we opted to an intermediate release of 3.8.0 that would focus on fixes to Gremlin semantics while 4.0.0 would focus on API and infrastructural changes.

In essence, 3.8.0 and 4.0.0 would carry the same exact Gremlin semantics, but you could expect driver and API incompatibility in 4.0.0. With this approach, those using 3.x wouldn’t be locked out of neat Gremlin features and the upgrade path to 3.8.x could focus strictly on Gremlin issues. When it was time to go to 4.x, users would know that coming from 3.8.x their Gremlin would have no behavioral issues and would only have to focus on infrastructural and API modifications. Ideally, those modifications would only be in driver configurations and resolving small, easily identifiable compile errors.

Ultimately, this strategy has kept development well focused within 3.8.0. While there are an extensive number of breaking changes, they come with the benefit of clear query semantics that are more readily optimizable by your favorite graph databases. While this upgrade may be more complex than most, it will be well worth the effort.

It’s hard to think about 3.8.0 without considering the impact of AI in the last couple of years. As I consider the earliest of those 75 or so releases, I don’t think we could have contemplated the tools we have at our disposal today for development. The 3.8.0 release made an important step to better connect TinkerPop to those tools with the introduction of a Gremlin MCP Server. While it is still just an alpha release, it offers some interesting features and positions TinkerPop to expand further in this area. It also offers something new in its Upgrade Documentation, providing a pre-packaged prompt) for AI-based coding agents that will help provide a risk assessment for upgrading an existing code base. This should help you better understand the tasks you will encounter in the upgrade process and allow you to plan your efforts accordingly.

The TinkerPop Community decided some years ago that it would deviate from its symbolic versioning system and move to a semantic versioning style that is more clearly understood. As a result, it is unlikely that we will ever again see 75 releases on the same major release line. It’s more likely TinkerPop 4.x, 5.x, and 6.x will come more rapidly. Having personally watched 3.x go by for ten years, it will be an interesting change in policy to get used to. I’m looking forward to the tail end of the this 3.x era with 3.8.0, as well as the next stage of development that the TinkerPop Community brings with 4.0.0.