Hi everyone, The 3.8-dev branch has now been opened, and I have deployed the initial snapshots to maven and published the docs.
Thanks, Cole From: Cole Greer <cole.gr...@improving.com.INVALID> Date: Monday, March 10, 2025 at 10:14 AM To: Dev Tinkerpop <dev@tinkerpop.apache.org> Subject: [DISCUSS] Introduction of 3.8-dev Hi everyone, I’d like to propose we create a new 3.8 release line. We continue to see ongoing work towards TinkerPop 4, which is aiming to simplify many of the internals of TinkerPop, and offer users a more consistent and stable experience. While that work is ongoing, I think that there may be a gap in which a 3.8 line may make sense. I’m envisioning 3.8 as a line which can retain pieces such as websockets and bytecode, while allowing some breaking changes to expand gremlin capabilities and clean up inconsistent semantics. I see the benefits of a potential 3.8 as being twofold: 1. As it is not dependent on any major internal reworks such as the promotion of HTTP over websockets, 3.8 would allow us to release meaningful features and improvements much sooner than when 4.0.0 will be ready for GA. 2. If we structure the releases where pieces such as upcoming gremlin language refinement goes to 3.8, this may serve as an effective bridge between 3.7 and 4. In this view, users would be able to upgrade to 3.8 to get the latest gremlin semantics without any added complexity that may arise from something like the protocol change in TP4, and then later users would find an easier path to upgrade to TP4 as that upgrade would focus on the internal mechanics of the drivers and server without much change to gremlin itself. If there are no concerns related to the development of a 3.8 line, I will open a new branch 3.8-dev (split from 3.7-dev) and then begin backporting any changes from master which make sense for 3.8. Under this branch structure, 3.7-dev would remain open for non-breaking changes, where 3.8-dev and master would each be accepting breaking changes. We would continue to merge changes up from 3.7-dev > 3.8-dev > master, however any changes which are not applicable to TinkerPop 4 (say something specifically addressing bytecode) could be dropped upon the merge to master. Please let me know any thoughts you have on the introduction of a new release line. Thanks, Cole