[DISCUSS] Runtime upgrades for 3.5-dev

[Ken Hu <ke...@bitquilltech.com.INVALID>]

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

AW: [DISCUSS] Runtime upgrades for 3.5-dev

[Florian Hockmann <fh...@florian-hockmann.de>]

Agreed, if the version we're using isn't supported any more, then I think
that it's more important to update to a supported version than to avoid the
breaking change.
Especially the release policy of Go makes it basically impossible for us to
stay on the same runtime version for a given minor release cycle.

-----Ursprüngliche Nachricht-----
Von: Cole Greer <Co...@improving.com.INVALID> 
Gesendet: Mittwoch, 8. Februar 2023 20:35
An: dev@tinkerpop.apache.org
Betreff: Re: [DISCUSS] Runtime upgrades for 3.5-dev

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 <ke...@bitquilltech.com.INVALID>
Date: Monday, February 6, 2023 at 2:42 PM
To: dev@tinkerpop.apache.org <de...@tinkerpop.apache.org>
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

Re: [DISCUSS] Runtime upgrades for 3.5-dev

[Cole Greer <Co...@improving.com.INVALID>]

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 <ke...@bitquilltech.com.INVALID>
Date: Monday, February 6, 2023 at 2:42 PM
To: dev@tinkerpop.apache.org <de...@tinkerpop.apache.org>
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