Moving the repository to github.com/apache/cassandra-gocql-driver

[martin-sucha]

Hi @michaelsembwever,

I've opened this issue to track discussion about moving the repository that we briefly touched at #1772 (comment):

Once the donation is voted upon and accepted, we will then ask ASF Infra to move this github repository.

The best approach, if possible, is to assign ASF Infra admin privileges to the repo and they will make the move (transfer organisation and rename project). With this approach GitHub automatically handles redirects (both in browser and from git on the command line, and in tools).

It is not clear to me if it is possible to do it in a backwards-compatible way and if so, how exactly.

We can't change the import path without breaking compatibility as third-party libraries depend on gocql,
but it might be possible to just rename the repository without changing the module name.

We should probably do some tests and research how such moves of other projects written in Go went.

cc @Zariel

[michaelsembwever]

@martin-sucha, would it be possible to delete the non-master branches now ? (do we have a fork we can keep that work archived in?)

[martin-sucha]

Sure, I can delete the non-master branches.

I don't have permissions to create a fork under the gocql organization. @Zariel could you please create gocql/archive fork before I delete the branches here?

[martin-sucha]

Another option to look into is keeping a stub package with type aliases and exported functions at github.com/gocql/gocql that would import the new package from github.com/apache/cassandra-gocql-driver and forward the calls there.

The question is if that would work with gocql forks that use the replace directive, as users of those would probably need to replace both the old and the new module in their go.mod.

cc @sylwiaszunejko

[michaelsembwever]

The IP Clearance vote has passed.

@martin-sucha, can you use any fork for now ? (you can push everything from it to a gocql/gocql-archive fork later) This is the only thing the transfer+rename is waiting on.

Also, once the extra branches are deleted, we will like to rename master to trunk to follow the practice in all the project's repos. This can happen after the transfer, just fyi.

[Zariel]

I would suggest setting up a vanity url so that we only ever need to change the import path once, something like go.apache.org/cassandra would be nice then we can point the repo and the branches to wherever the source is hosted. We can leave this repo as an archive and point to the new import path.

[michaelsembwever]

We can leave this repo as an archive and point to the new import path.

We were hoping to transfer and rename this gh repo to apache/cassadra-gocql-driver

That would result in github.com/gocql/gocql requests automatically redirecting to github.com/apache/cassadra-gocql-driver
(It is beneficial that folk are automatically taken to the correct location, rather than having to readme and manually do it…)

Hence the request for a separate repo as the archive.
(But i'm not up to date with how the go packaging goes…)

WRT a vanity url, if such a thing existed it would need to be go.cassandra.apache.org (but we'd likely get push back from ASF Infra as there is overhead to maintaining each custom url).

[martin-sucha]

I've deleted the logger-on-session, v2.dev and v2/remove-iter-scan branches. Archive copy of those is at https://github.com/martin-sucha/gocql-archive

The main concern I have at this point is whether it is safe to do the repo rename (redirect) from the Go compatibility point of view (whether the go.mod references will still work).

[michaelsembwever]

I've deleted the logger-on-session, v2.dev and v2/remove-iter-scan branches. Archive copy of those is at https://github.com/martin-sucha/gocql-archive

Thanks!

The main concern I have at this point is whether it is safe to do the repo rename (redirect) from the Go compatibility point of view (whether the go.mod references will still work).

I don't know 🤷
Is this something we can figure out, and fix if need be, after the move ?

[martin-sucha]

Is this something we can figure out, and fix if need be, after the move ?

I would prefer a more conservative approach. Github says there are 7000 dependent packages in about 4400 repositories, so breaking the imports could do a lot of damage until we fix the issue.

It seems that go-redis project did something similar, although they released a new major version at the same time.

[michaelsembwever]

It seems that go-redis project did something similar, although they released a new major version at the same time.

This looks like what we want to do too.
https://github.com/go-redis/redis now redirects to https://github.com/redis/go-redis

If we transfer+rename the repo, change the project coordinates, and bump to v2, are there any objections or concerns remaining ?

The only thing I can think of is if we want to do a patch release off an older version.
My suggestion is that we introduce v2.1 quickly, so that v2.0 is basically the same as v1.9 and where such patch releases can be applied to…

[michaelsembwever]

ping @martin-sucha , any answers/opinions on this^?

[martin-sucha]

Hi @michaelsembwever , sorry for the late reply.

If we transfer+rename the repo, change the project coordinates, and bump to v2, are there any objections or concerns remaining ?

The only thing I can think of is if we want to do a patch release off an older version.

I have created a testing repository and confirm that renaming the repository should work as expected.
Should be backwards-compatible as long as we keep the github.com/gocql/gocql module name for v1.
Please proceed with moving the repository.

Renaming the Go module is a backwards-incompatible change, so best would be to do it at the same time as bumping to v2. It seems to me that in addition to changing the module path to the new location, bump to v2 should provide users also some benefits as it will force the ecosystem to upgrade — all the libraries like gocqlx will need to be updated to support v2 as they use interfaces like gocql.Marshaler in their APIs. The v2 could contain compatibility breaking changes in the API, such as removing the global logger and others. It seems to me that there is no rush to do the Go module rename quickly after moving the repository, as minor versions could be released using the old module name.

A decision needs to be made as to where the v2 code will live (see https://go.dev/blog/v2-go-modules) cc @joao-r-reis @jfleming-ic :

• It could be in v2 subdirectory of the default branch.
• It could be in v2 branch.
• Keeping the latest version in the default branch and having a copy of v1 in the v1 branch might also work.

The go-redis repository has latest v9 code in the default branch and some older v9 code in v9 branch. I haven't looked at how other projects do it.

This needs to be done in a way that will keep the old v1 import paths working, which would also allow you to release minor v1 versions if needed.

[michaelsembwever]

Thanks for following up @martin-sucha

Keeping the latest version in the default branch and having a copy of v1 in the v1 branch might also work.

This has my vote.

[joao-r-reis]

Keeping the latest version in the default branch and having a copy of v1 in the v1 branch might also work.

This has my vote.

Same here. It looks like this is the approach that go-redis is using as @martin-sucha mentioned. I found another example that is using this approach: pgx. We do have to keep in mind that tools that are not "version aware" may not work correctly but I don't think it's a big deal. Quoting the go.dev blog post:

Other strategies may keep major versions on separate branches. However, if v2+ source code is on the repository’s default branch (usually master), tools that are not version-aware — including the go command in GOPATH mode — may not distinguish between major versions.

[michaelsembwever]

If there's no further comments or objections then I will initiate the request to ASF Infra to transfer and rename the repo.
Creating the v1 branch will be done immediately after.

[joao-r-reis]

Creating the v1 branch will be done immediately after.

Does it make sense to do that right away? Don't we want to address some of the issues that Martin mentioned that require breaking changes to the API? We could keep using the old module name until we decide to release a v2 and at that point we can rename the module?

[michaelsembwever]

Does it make sense to do that right away?

@martin-sucha , can and will you create the v1 branch before the transfer+rename ?

[joao-r-reis]

Sorry I meant to suggest that we don't want to create the v1 branch now at all, we should wait until we can work on stuff that we want to release on a v2 in the near future and only then we should rename the module and create the v1 branch. I don't think it would be great to tie a v2 with the ASF repo transfer.

[michaelsembwever]

oh, my bad.

Ok then. Moving ahead with requesting ASF Infra to do the transfer+rename.

[michaelsembwever]

https://issues.apache.org/jira/browse/INFRA-25979

[michaelsembwever]

@martin-sucha , @Zariel ,

see Drew's request for what he needs to do the transfer+rename

I'd be happy to take care of this for you. If you would: Grant my GitHub user [~dfoulks1] Administrator permissions to the gocql organization.

If the level of permissions is too much for your comfort, we do have an intermediate org we can use to conduct the transfer.

Please let me know how you'd like to proceed.

from https://issues.apache.org/jira/browse/INFRA-25979?focusedCommentId=17868035&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17868035

[Zariel]

@martin-sucha , @Zariel ,

see Drew's request for what he needs to do the transfer+rename

I'd be happy to take care of this for you. If you would: Grant my GitHub user [~dfoulks1] Administrator permissions to the gocql organization.
If the level of permissions is too much for your comfort, we do have an intermediate org we can use to conduct the transfer.
Please let me know how you'd like to proceed.

from https://issues.apache.org/jira/browse/INFRA-25979?focusedCommentId=17868035&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17868035

Done

[michaelsembwever]

done: https://github.com/apache/cassandra-gocql-driver

Immediate actions:

• rename master to trunk (per project-wide practice)
• a few asterisks to add to names in NOTICE who gave late approval for their contributions to re-assign to the ASF
• start working on stuff listed in CASSANDRA-19723

[martin-sucha]

Thanks!

One of the first steps should be updating the CONTRIBUTING.md to clarify what changed with the donation to the ASF and how to handle pull requests that were opened before the move/license change.

[michaelsembwever]

ticket for master to trunk rename: https://issues.apache.org/jira/browse/INFRA-25998