I'm not sure that now is the right time to have this foundation and lite split. What we've seen in the past is that users often ask for features that exist in other GLVs and there has been an emphasis recently on parity amongst the GLVs, especially for 4.x. While agents can certainly help us bridge this gap, what I've noticed lately though is that there is still a burden of reviewing that agents aren't completely capable of doing by themselves. This means that there still needs to be an active contributor who has some knowledge in that particular area where we are adding a new module. For now, I think we have to either go with the Tinkubator or stay with the module being third party. However, things are changing rapidly and we probably need to revisit this discussion again in a couple of months.
On Mon, Jun 8, 2026 at 5:04 AM Stephen Mallette <[email protected]> wrote: > A pull request landed over the weekend offering a Dart GLV. As little as a > year or two ago, I think there would have been concerns for long standing > support of such a contribution. We might have asked that the contribution > live in its own repo for a while to see how its usership developed. It > might have fast-tracked committership discussions. I'm not sure any of that > is the path anymore as I'd fully expect to see more pull requests like this > in the future with agents churning them out in a day or so and, on the > TinkerPop side, agents enabling management of a larger and larger code base > without nearly as much overhead. > > Perhaps there needs to be some revised thinking around how TinkerPop > considers language variants, particularly as they advance in functionality > (think how 4.x gets us subgraph and executable Gremlin subsets). I think > TinkerPop might consider the idea of having two types of language variants: > > 1. foundational - these would be like the ones officially supported right > now, with a full capability set and clear user base, and acts as a primary > driver for a specific environment/runtime - like, Java for the JVM, over > say Scala or Kotlin > 2. lite - something that doesn't fall into "complete" for some reason - > like say Clojure or Groovy would fall here as they would probably be > written as wrappers to Java or Dart because it lacks a feature required of > foundational or simply because it's "new" and the user base isn't clear. In > Dart's specific case it could graduate to foundational should those issues > resolve because it targets a specific runtime we don't currently reach. > > Lite would still get the same treatment as foundational from a release > perspective and, while that traditionally creates added burden on the > release manager, agents will be helping in this area too as the release > process automates and simplifies. I don't know that there is an argument > using release complexity anymore - consider Apache Airflow managing the > release of dozens/hundreds of their third-party contributed "providers", > including TinkerPop. > > I'm not sure I have this all thought out, but it begs discussion because I > don't think the old ideas around this work well anymore. I sense that > agents should let TinkerPop feel less constrained about the languages it > supports and offer a clear way to accept and offer them as official ways to > work with TinkerPop-enabled graphs. > > A couple of side points to all this...First, perhaps language variants > could be separated from the core release cycle at some point, now that we > have a stable serializer/protocol. Not sure what that would look like but > it would give releases a bit more flexibility. TinkerPop might need that > flexibility as the variants become more feature-rich and numerous. We > could, again, look to Airflow for their management processes > for inspiration. Second, perhaps we should consider reviving the > Tinkubator, an early holding place for TinkerPop ideas that weren't really > ready for release. That might let TinkerPop have a place for clear > experimentation. That space might be useful in a time where agents let us > move so quickly on ideas that we might get ahead of ourselves, but don't > want to leave an idea untried. >
