[DISCUSS] Python GLV Patch Release

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

Hi everyone,

I’ve been tracking TINKERPOP-2810<https://issues.apache.org/jira/browse/TINKERPOP-2810> since the 3.6.2 release went live and it seems this has become a serious pain point for a significant number of users. As of right now the fix for this has been merged into 3.5-dev and 3.6-dev (PR<https://github.com/apache/tinkerpop/pull/1958>). By my count there are at least 6 unique users requesting a release be made with this fix.

I see 3 options to meet these requests:

1: Schedule a full tinkerpop release. The main concerns here is that the release process is quite labour intensive and slow. Also since little time has passed since the previous release, this release would bring very few changes to non-python users.

2: Initiate a patch release for the python GLV only. This would be a release of versions 3.5.5.1 and 3.6.2.1 for the python GLV. This process would shed a little of the overhead from option 1 (namely the docs portion of the release), but overall would still be slow as we would still need to go through the process of a full source release.

3: Publish a python release candidate. In order to get this fix in the hands of gremlin python users as quickly as possible, we could create a 3.5.6-rc0 and 3.6.3-rc0 release candidates and publish convenience binaries for these. The upside here is that publishing RC’s is a much more lightweight process than a full official release and we could get this fix into the hands of users much quicker. A potential downside of this approach is there may be some users in production environments which prevent them from making use of a release candidate version.

My proposal is that we move forward with option 3 as it is the quickest path to alleviate this problem for python users. I would ask that any users who are having issues with the current aiohttp version restriction respond to this thread to let us know if publishing a release candidate would be helpful for them. I would also like to ask users if they are seeking a fix in the 3.6.x only or if we'd want a 3.5.x release too.

Regards,

Cole Greer

Re: [DISCUSS] Python GLV Patch Release

[Stephen Mallette <sp...@gmail.com>]

I quickly did the release candidate deployments for 3.6.3rc1/3.5.6rc1.
Please recall that these are development versions meant as a convenience
only. They are not to be promoted publicly as releases. Thanks Cole.

On Mon, Feb 13, 2023 at 4:34 PM Cole Greer <Co...@improving.com.invalid>
wrote:

> Hi everyone,
>
> I’ve been tracking TINKERPOP-2810<
> https://issues.apache.org/jira/browse/TINKERPOP-2810> since the 3.6.2
> release went live and it seems this has become a serious pain point for a
> significant number of users. As of right now the fix for this has been
> merged into 3.5-dev and 3.6-dev (PR<
> https://github.com/apache/tinkerpop/pull/1958>). By my count there are at
> least 6 unique users requesting a release be made with this fix.
>
> I see 3 options to meet these requests:
>
> 1: Schedule a full tinkerpop release. The main concerns here is that the
> release process is quite labour intensive and slow. Also since little time
> has passed since the previous release, this release would bring very few
> changes to non-python users.
>
> 2: Initiate a patch release for the python GLV only. This would be a
> release of versions 3.5.5.1 and 3.6.2.1 for the python GLV. This process
> would shed a little of the overhead from option 1 (namely the docs portion
> of the release), but overall would still be slow as we would still need to
> go through the process of a full source release.
>
> 3: Publish a python release candidate. In order to get this fix in the
> hands of gremlin python users as quickly as possible, we could create a
> 3.5.6-rc0 and 3.6.3-rc0 release candidates and publish convenience binaries
> for these. The upside here is that publishing RC’s is a much more
> lightweight process than a full official release and we could get this fix
> into the hands of users much quicker. A potential downside of this approach
> is there may be some users in production environments which prevent them
> from making use of a release candidate version.
>
> My proposal is that we move forward with option 3 as it is the quickest
> path to alleviate this problem for python users. I would ask that any users
> who are having issues with the current aiohttp version restriction respond
> to this thread to let us know if publishing a release candidate would be
> helpful for them. I would also like to ask users if they are seeking a fix
> in the 3.6.x only or if we'd want a 3.5.x release too.
>
> Regards,
>
> Cole Greer
>