Hi Cole and HugeGraph communities, Apologies for the delay. My previous email from another address did not reach the list, so I am resending it here.
Thanks, Cole, for reaching out, and thanks, Imba, for providing the context. I am currently working on the HugeGraph query engine upgrade effort. To make the follow-up easier to track publicly, I have created an umbrella issue here: https://github.com/apache/hugegraph/issues/3069 This issue summarizes the current migration direction, the baseline upgrade scope, and the proposed follow-up workstreams. The current baseline migration is focused first on compatibility with TinkerPop 3.7.6 and Groovy 4.0.25, including dependency alignment, API adaptation, serializer and remote-client compatibility, runtime behavior, and test stabilization. To keep the work reviewable, we plan to track Java 17 readiness, the Groovy sandbox review, PD / Store / HStore validation, benchmark methodology, release metadata, and future TinkerPop 3.8 exploration as separate follow-up workstreams. Related PRs and progress updates will be linked from the umbrella issue. We would really appreciate feedback from the TinkerPop community on the following areas: - Important provider-facing behavior changes between TinkerPop 3.5.x and 3.7.x that HugeGraph should pay particular attention to. - Recommended validation steps or provider-test coverage for graph providers upgrading to the 3.7.x line. - Known Groovy 4 integration concerns around Gremlin script execution. - Early migration risks or compatibility checks that we should consider for a future TinkerPop 3.8 exploration. - Risks or compatibility checks to consider when upgrading from Java 11 to Java 17, especially in relation to TinkerPop components. We can continue the detailed technical discussion mainly in the GitHub issue and use the mailing list for important public updates. Best, Contrue 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 > > > > >
