Hi Ken, I agree with your suggestions here. In general I think that avoiding major runtime version bumps during the lifespan of a major tinkerpop release branch is the right goal. I agree that ensuring we are always releasing tinkerpop on actively supported runtimes takes precedence over that goal though. I think the procedure you described for upgrading runtimes is a good approach.
Thanks, Cole From: Ken Hu <[email protected]> Date: Monday, February 6, 2023 at 2:42 PM To: [email protected] <[email protected]> Subject: [DISCUSS] Runtime upgrades for 3.5-dev Hi All, Our current developer documentation states that "In general, TinkerPop will attempt to support the current LTS version for a particular major version for the lifetime of its minor and patch releases." Given the length of time that we are currently supporting minor versions of TinkerPop and how quickly some LTS versions can change (e.g. Go only supports versions for one year), I would suggest that we loosen this to the following: "In general, TinkerPop will attempt to support the current LTS version of a runtime for all currently maintained versions. A deprecation notice will be applied to the last release of TinkerPop that will support that outdated runtime and the runtime will be updated in the following release." This would allow us to more easily change the LTS version of a runtime during the maintenance window of a TinkerPop minor release. The two examples that could be used right now to demonstrate this are Node.js and Go. Currently, 3.5-dev is using Node 10 which hasn't been supported since April 2021 and Golang 1.17 which hasn't been supported since August 2022. I propose that we change the wording in our documentation about runtime support and then go ahead and add a deprecation warning to 3.5.6 about Go and Node.js and then update them in 3.5.7. Thanks, Ken
