Hi Contrue, Thanks for the update, I'll definitely follow the GitHub issue.
It's a bit hard for me to predict the most likely sources of friction with your upgrades as I'm not that familiar with the internals of HugeGraph. I'm definitely more than willing to help answer questions for any specific problems as they come up. I see you've asked similar feedback in the TinkerPop discord, which is definitely the best place to get answers from a broader selection of the TinkerPop community. As already mentioned in our discord, our upgrade documentation (https://tinkerpop.apache.org/docs/3.7.6/upgrade/) is where we try to collect all important warnings and information needed for TInkerPop upgrades. The 3.6.0 and 3.7.0 sections naturally contain the biggest changes/risks, but there is potentially important information throughout. There are a few changes which come to mind which may be impactful: 1. Properties on Elements - Traditionally gremlin-server returned vertices and edges without any of their properties to minimize size, this has been reversed by default in 3.7.0. Any old serializers which are not expecting properties to exist may fail to deserialize the updated elements. 2. Added steps - There's a whole bunch of new gremlin steps added since 3.5. 3.6 added the mergeV and mergeE steps, and 3.7 added a whole bunch of string, list, and date manipulation steps. As for the risks from the Groovy upgrade, it may be worth trying to switch from the GremlinGroovyScriptEngine to GremlinLangScriptEngine (ANTLR-based, processes pure gremlin only). I'm not sure the extent that HugeGraph utilizes groovy beyond pure gremlin traversals, but if this switch is possible, it really limits the potential impacts from groovy upgrades, and it better aligns HugeGraph with TinkerPop's long term direction (GremlinLang is steadily replacing GremlinGroovy). If this switch is not feasible, that's ok, as GremlinGroovyScriptEngine is unlikely to be dropped anytime soon, although it is disabled by default as of TinkerPop 4 (not yet released). There's one last thing which I've already mentioned in private but is worth putting here for visibility, TinkerPop 3.7.7 is expected to release soon, and it will include a bunch of dependency bumps to address various vulnerabilities. That will likely be a good version to target once its out. Thanks, Cole Greer On 2026/07/12 12:39:13 true con wrote: > 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 > > > > > > > > >
