CLA Assistant Lite bot:
Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

I have read the CLA Document and I hereby sign the CLA

1 out of 2 committers have signed the CLA.
✅ @kylecarbs
❌ @coryb
_{You can retrigger this bot by commenting recheck in this Pull Request}

Not sure how to sign the CLA. We have a corporate CLA for Netflix.

@coryb you have to type a comment with

I have read the CLA Document and I hereby sign the CLA

Do we need this right now?

For the go mod requires semantic versioning with versions greater than 1.x, we are only on v2.x.x to remove any possible confusion with our first version of the product. Semantically, we are on v1.x.x of this repository, but for business reasons, we jump to v2.x.x.

The first version of the product is closed source, so for go module reasons, the two products will never be confused externally.

Additional question,

Does this mean that anyone importing github.com/coder/coder might get our v0.x.x version of the code, and not the latest?

Reading https://go.dev/ref/mod#major-version-suffixes

If an old package and a new package have the same import path, the new package must be backwards compatible with the old package.

I will defer judgment to others, but these imports are backwards compatible to the previous v0.x.x. I think the only package that is created for external use is the codersdk package.

I am not blocking this PR btw, just curious

If an old package and a new package have the same import path, the new package must be backwards compatible with the old package.

I think this only refers to releases within the same major version stream.

That document also says:

Starting with major version 2, module paths must have a major version suffix like /v2 that matches the major version. For example, if a module has the path example.com/mod at v1.0.0, it must have the path example.com/mod/v2 at version v2.0.0.

and

By definition, packages in a new major version of a module are not backwards compatible with the corresponding packages in the previous major version.

I am pretty fuzzy on the go.mod version requirements myself, I just know that we cant import the latest coder release because it fails:

go get github.com/coder/coder@v2.0.2
go: github.com/coder/coder@v2.0.2: invalid version: module contains a go.mod file, so module path must match major version ("github.com/coder/coder/v2")

go get github.com/coder/coder/v2@v2.0.2
go: github.com/coder/coder@v2.0.2: invalid version: module contains a go.mod file, so module path must match major version ("github.com/coder/coder/v2")

Anyway, it looks like the PR doesn't work because of several other places where the package name is hard-coded in generators. I fixed the protos and some locations in ./scripts, but there seem to be more. I need to fix my dev environment to run these things locally so probably makes sense for someone else to recreate this work, or patch my PR.

I am pretty fuzzy on the go.mod version requirements myself, I just know that we cant import the latest coder release because it fails:

go get github.com/coder/coder@v2.0.2
go: github.com/coder/coder@v2.0.2: invalid version: module contains a go.mod file, so module path must match major version ("github.com/coder/coder/v2")

go get github.com/coder/coder/v2@v2.0.2
go: github.com/coder/coder@v2.0.2: invalid version: module contains a go.mod file, so module path must match major version ("github.com/coder/coder/v2")

Ooof this is enough validation for me. We have a few generators yea 😢

Doing #9072 instead

closing in favor of #9072