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.
