Thanks for kicking off the discussion here Stephen. In the short term, I think the return of the Tinkubator is the right home for newly-developed feature-frugal GLVs. The foundational/lite GLV model might be right long-term, but I'm not sure I'm ready to adopt it right now.
Looking at the current gremlin-dart PR as a case study, I actually don't want to accept it into TinkerPop in a "reduced state" without real intention for it to one day "graduate" into a proper GLV. I think the Tinkubator is the right platform for this. It gives us a good home for an experimental driver which is lacking some features and has unproven demand. From there, we can throw some marketing behind it, assess the demand and decide where to move forward. With proven demand, I'd ideally like to see us eventually close the feature gap and graduate gremlin-dart as a foundational GLV. If in 1-2 years time we see gremlin-dart is getting consistent usage, but not enough developer investment to close the feature gap, then at that point I think we should consider a secondary graduation path to a "lite" driver. I think the Tinkubator itself would be good platform for us to move faster with more experimental concepts. I've been thinking about putting together some semi-standardized DSLs for common graph algorithms (beyond the current computer steps) as well as potential integrations with agentic memory systems. The Tinkubator would be a good place for us to try new things without committing to long-term support for experiments which ultimately bear little value. Regards, Cole On 2026/06/08 12:04:25 Stephen Mallette 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. >
