Hi Imba, Thanks for your response. It makes sense that upgrades have been delayed if the upgrade effort is so large. As you do eventually go through the upgrade process, if you come up with any suggestions on changes we can make in TinkerPop which would make upgrades easier to consume, I'd be happy to hear that feedback in our dev maillist or Discord.
If your goals are to get to Java 17 and Groovy 4, a jump straight to 3.7.x would likely involve the least effort. It would likely be best to go straight to 3.7.6 or the soon to be released 3.7.7. 3.6 and 3.7 together add quite a few new steps to Gremlin which make the language a lot more convenient and expressive. I'm not sure if you will find it necessary to override many of these new steps or if you will be able to easily use our default implementations. If you eventually intend to get to TinkerPop 4, I think it's worth the extra effort to initially jump to 3.8.x. This is perhaps a more difficult upgrade for you, as we did alter the semantics of some existing steps in places where we often find users struggle or results are unpredictable (see https://tinkerpop.apache.org/docs/3.8.1/upgrade/#_modified_step_behavior). Our goal is for the Gremlin semantics to remain the same when jumping from 3.8 to 4. 3.8 was focused on making all of the major query language changes we've been considering for years within TinkerPop 3.x, and then TinkerPop 4 is focused on modernizing all of the surrounding infrastructure in TinkerPop, while maintaining the same Gremlin semantics as a bridge to TinkerPop 3.8. We haven't yet gotten Java 21 support added for TinkerPop 4, but it is something we are looking at and I hope to see land in the final 4.0.0 release. We don't currently have any plans to build Java 21 support into TinkerPop 3.x. > We have community devs actively leading this effort right now, including > updating and breaking down the proposal. You are more than welcome to join > in—your help would be a huge boost to speeding up the upgrade process. Where are these discussions and work taking place? I'm not sure how much help I can offer at the moment, but I'd love to follow along and help anywhere I can. Thanks, Cole On 2026/06/21 14:50:29 Imba Jin wrote: > Hi Cole, > > Thanks so much for reaching out! > > To put it simply, the main reason we haven't kept up with the newer versions > is that HugeGraph overrides certain steps and enforces its own constraints on > some schema definitions (e.g., whether GraphMetaElement can be null). Because > of this, upgrading isn't a drop-in or low-cost task, and it comes with quite > a few potential compatibility risks. This has indeed caused some feature and > security issues, which has been a major headache for us. > > However, now that the HugeGraph community has graduated from incubator > status, upgrading TinkerPop has been officially put on the agenda. We've > already drafted an initial proposal and started working on it. Our > preliminary plan is to jump straight from 3.5 to 3.7/3.8, based on the > following goals: > 1. Achieve compatibility with Java 17 + Groovy 4 + TinkerPop 3.x at the > lowest modification cost. > 2. If TinkerPop 4.0 already supports Java 21, we'd love to test and migrate > to it as soon as possible. > > We have community devs actively leading this effort right now, including > updating and breaking down the proposal. You are more than welcome to join > in—your help would be a huge boost to speeding up the upgrade process. > > Just wanted to give you a quick reply first. Our team members will follow up > on this soon. We can also open a GitHub discussion or issue for official > communication, as some of our developers don't check emails very often. > > Best, > > Imba Jin - Behalf the HugeGraph PMC > > On 2026/06/15 19:40:13 Cole Greer wrote: > > Hi everyone, > > > > I'm one of the maintainers of Apache TinkerPop, and I was taking a look > > at how HugeGraph > > utilizes TinkerPop when I noticed that HugeGraph is consuming TinkerPop > > 3.5.1 (if I > > understood this correctly). This is quite an old version of TinkerPop > > (2021), and I wanted > > to reach out and ask if there's any reason why HugeGraph has remained > > pinned to this > > version for so long. > > > > There's been quite a few upgrades to TinkerPop in the last 5 years > > including plenty of > > new Gremlin steps to expand language capability, improved connection > > management stability, > > and plenty of performance and security enhancements. I'm curious if > > there are any blockers > > which have prevented HugeGraph from upgrading, or if there has been a > > lack of demand for > > new features. > > > > I'd love to have a discussion with folks here about what role (if any) > > you see TinkerPop > > playing in HugeGraph's long-term future, as well as what can we do on > > the TinkerPop side > > to support this vision. > > > > Please let me know if you have any thoughts regarding the TinkerPop > > upgrade path in > > HugeGraph, or the long-term role of TinkerPop in the project. > > > > Thanks, > > Cole > > > > >
