Version in go.mod could be lowered
#520
Comments
|
Hmm, do you have any error messages to share about what you were running into? Our intention is to always support the 2 latest major Go versions, both of which we run in CI, so I’m curious why that works if you’re having issues due to the version specifier. |
|
Yeah, when I upgrade River to 0.11, I get this output: At which point my Then when I try to build inside the container, the error I get is: There's a bunch of stuff in https://go.dev/doc/toolchain I figured out if I build with I think the key line is this one:
From what I can parse, if you are targeting go 1.21 and 1.22, I think you should have
Interesting! Check out the 'Setup Go 1.21' output here: https://github.com/riverqueue/river/actions/runs/10296721804/job/28498552958 |
|
lol yep, thank you for catching that and it’s why I was asking! Pretty important we get this dialed in 🙂 should be able to fix this up later today and get in the next release. |
brandur
added a commit
that referenced
this issue
Aug 9, 2024
This one related to #520, in which it turns out that our Go 1.21 build step has actually been automatically upgrading itself to Go 1.22, so under the radar that we didn't notice. Here, leverage a Go "toolchain" to establish a preferred version of Go for the project, but keeping a `go` directive in `go.mod`s that's at the 1.21 lower bound that we're trying to support. The presence of a `toolchain` directive prevents `go mod tidy` from upgrading the `go` directive to the latest version of Go installed. I found the easiest way to add the toolchain directive to be with `go get` [2] like: go get [email protected] [email protected] Maintaining this correctly is going to be a little tricky. This is one of those classic Go features that kind of works, but various Go commands will perform all kinds of confusing behavior like stripping directives out of your file if there's anything even a tiny bit wrong, and with no explanation whatsoever. I found that to get this working I had to started with the "inner" dependencies like `rivershared` and `rivertype`, `go get` Go/toolchain there first, then work my way up the stack all the way up to the main project. I'm going to try and follow this up with some tooling to help make this easier for ourselves, and a build check that verifies in CI that nothing gets accidentally regressed as we make changes because this is _very_ easy to do accidentally. Fixes #520. [1] https://go.dev/doc/toolchain [2] https://go.dev/doc/toolchain#get
brandur
added a commit
that referenced
this issue
Aug 9, 2024
This one related to #520, in which it turns out that our Go 1.21 build step has actually been automatically upgrading itself to Go 1.22, so under the radar that we didn't notice. Here, leverage a Go "toolchain" to establish a preferred version of Go for the project, but keeping a `go` directive in `go.mod`s that's at the 1.21 lower bound that we're trying to support. The presence of a `toolchain` directive prevents `go mod tidy` from upgrading the `go` directive to the latest version of Go installed. I found the easiest way to add the toolchain directive to be with `go get` [2] like: go get [email protected] [email protected] Maintaining this correctly is going to be a little tricky. This is one of those classic Go features that kind of works, but various Go commands will perform all kinds of confusing behavior like stripping directives out of your file if there's anything even a tiny bit wrong, and with no explanation whatsoever. I found that to get this working I had to started with the "inner" dependencies like `rivershared` and `rivertype`, `go get` Go/toolchain there first, then work my way up the stack all the way up to the main project. I'm going to try and follow this up with some tooling to help make this easier for ourselves, and a build check that verifies in CI that nothing gets accidentally regressed as we make changes because this is _very_ easy to do accidentally. Fixes #520. [1] https://go.dev/doc/toolchain [2] https://go.dev/doc/toolchain#get
brandur
added a commit
that referenced
this issue
Aug 9, 2024
This one related to #520, in which it turns out that our Go 1.21 build step has actually been automatically upgrading itself to Go 1.22, so under the radar that we didn't notice. Here, leverage a Go "toolchain" to establish a preferred version of Go for the project, but keeping a `go` directive in `go.mod`s that's at the 1.21 lower bound that we're trying to support. The presence of a `toolchain` directive prevents `go mod tidy` from upgrading the `go` directive to the latest version of Go installed. I found the easiest way to add the toolchain directive to be with `go get` [2] like: go get [email protected] [email protected] Maintaining this correctly is going to be a little tricky. This is one of those classic Go features that kind of works, but various Go commands will perform all kinds of confusing behavior like stripping directives out of your file if there's anything even a tiny bit wrong, and with no explanation whatsoever. I found that to get this working I had to started with the "inner" dependencies like `rivershared` and `rivertype`, `go get` Go/toolchain there first, then work my way up the stack all the way up to the main project. I'm going to try and follow this up with some tooling to help make this easier for ourselves, and a build check that verifies in CI that nothing gets accidentally regressed as we make changes because this is _very_ easy to do accidentally. Fixes #520. [1] https://go.dev/doc/toolchain [2] https://go.dev/doc/toolchain#get
brandur
added a commit
that referenced
this issue
Aug 9, 2024
This one related to #520, in which it turns out that our Go 1.21 build step has actually been automatically upgrading itself to Go 1.22, so under the radar that we didn't notice. Here, leverage a Go "toolchain" to establish a preferred version of Go for the project, but keeping a `go` directive in `go.mod`s that's at the 1.21 lower bound that we're trying to support. The presence of a `toolchain` directive prevents `go mod tidy` from upgrading the `go` directive to the latest version of Go installed. I found the easiest way to add the toolchain directive to be with `go get` [2] like: go get [email protected] [email protected] Maintaining this correctly is going to be a little tricky. This is one of those classic Go features that kind of works, but various Go commands will perform all kinds of confusing behavior like stripping directives out of your file if there's anything even a tiny bit wrong, and with no explanation whatsoever. I found that to get this working I had to started with the "inner" dependencies like `rivershared` and `rivertype`, `go get` Go/toolchain there first, then work my way up the stack all the way up to the main project. I'm going to try and follow this up with some tooling to help make this easier for ourselves, and a build check that verifies in CI that nothing gets accidentally regressed as we make changes because this is _very_ easy to do accidentally. Fixes #520. [1] https://go.dev/doc/toolchain [2] https://go.dev/doc/toolchain#get
brandur
added a commit
that referenced
this issue
Aug 9, 2024
This one related to #520, in which it turns out that our Go 1.21 build step has actually been automatically upgrading itself to Go 1.22, so under the radar that we didn't notice. Here, leverage a Go "toolchain" to establish a preferred version of Go for the project, but keeping a `go` directive in `go.mod`s that's at the 1.21 lower bound that we're trying to support. The presence of a `toolchain` directive prevents `go mod tidy` from upgrading the `go` directive to the latest version of Go installed. I found the easiest way to add the toolchain directive to be with `go get` [2] like: go get [email protected] [email protected] Maintaining this correctly is going to be a little tricky. This is one of those classic Go features that kind of works, but various Go commands will perform all kinds of confusing behavior like stripping directives out of your file if there's anything even a tiny bit wrong, and with no explanation whatsoever. I found that to get this working I had to started with the "inner" dependencies like `rivershared` and `rivertype`, `go get` Go/toolchain there first, then work my way up the stack all the way up to the main project. I'm going to try and follow this up with some tooling to help make this easier for ourselves, and a build check that verifies in CI that nothing gets accidentally regressed as we make changes because this is _very_ easy to do accidentally. Fixes #520. [1] https://go.dev/doc/toolchain [2] https://go.dev/doc/toolchain#get
brandur
added a commit
that referenced
this issue
Aug 9, 2024
This one related to #520, in which it turns out that our Go 1.21 build step has actually been automatically upgrading itself to Go 1.22, so under the radar that we didn't notice. Here, leverage a Go "toolchain" to establish a preferred version of Go for the project, but keeping a `go` directive in `go.mod`s that's at the 1.21 lower bound that we're trying to support. The presence of a `toolchain` directive prevents `go mod tidy` from upgrading the `go` directive to the latest version of Go installed. I found the easiest way to add the toolchain directive to be with `go get` [2] like: go get [email protected] [email protected] Maintaining this correctly is going to be a little tricky. This is one of those classic Go features that kind of works, but various Go commands will perform all kinds of confusing behavior like stripping directives out of your file if there's anything even a tiny bit wrong, and with no explanation whatsoever. I found that to get this working I had to started with the "inner" dependencies like `rivershared` and `rivertype`, `go get` Go/toolchain there first, then work my way up the stack all the way up to the main project. I'm going to try and follow this up with some tooling to help make this easier for ourselves, and a build check that verifies in CI that nothing gets accidentally regressed as we make changes because this is _very_ easy to do accidentally. Fixes #520. [1] https://go.dev/doc/toolchain [2] https://go.dev/doc/toolchain#get
brandur
added a commit
that referenced
this issue
Aug 9, 2024
This one related to #520, in which it turns out that our Go 1.21 build step has actually been automatically upgrading itself to Go 1.22, so under the radar that we didn't notice. Here, leverage a Go "toolchain" to establish a preferred version of Go for the project, but keeping a `go` directive in `go.mod`s that's at the 1.21 lower bound that we're trying to support. The presence of a `toolchain` directive prevents `go mod tidy` from upgrading the `go` directive to the latest version of Go installed. I found the easiest way to add the toolchain directive to be with `go get` [2] like: go get [email protected] [email protected] Maintaining this correctly is going to be a little tricky. This is one of those classic Go features that kind of works, but various Go commands will perform all kinds of confusing behavior like stripping directives out of your file if there's anything even a tiny bit wrong, and with no explanation whatsoever. I found that to get this working I had to started with the "inner" dependencies like `rivershared` and `rivertype`, `go get` Go/toolchain there first, then work my way up the stack all the way up to the main project. I'm going to try and follow this up with some tooling to help make this easier for ourselves, and a build check that verifies in CI that nothing gets accidentally regressed as we make changes because this is _very_ easy to do accidentally. Fixes #520. [1] https://go.dev/doc/toolchain [2] https://go.dev/doc/toolchain#get
brandur
added a commit
that referenced
this issue
Aug 9, 2024
This one related to #520, in which it turns out that our Go 1.21 build step has actually been automatically upgrading itself to Go 1.22, so under the radar that we didn't notice. Here, leverage a Go "toolchain" to establish a preferred version of Go for the project, but keeping a `go` directive in `go.mod`s that's at the 1.21 lower bound that we're trying to support. The presence of a `toolchain` directive prevents `go mod tidy` from upgrading the `go` directive to the latest version of Go installed. I found the easiest way to add the toolchain directive to be with `go get` [2] like: go get [email protected] [email protected] Maintaining this correctly is going to be a little tricky. This is one of those classic Go features that kind of works, but various Go commands will perform all kinds of confusing behavior like stripping directives out of your file if there's anything even a tiny bit wrong, and with no explanation whatsoever. I found that to get this working I had to started with the "inner" dependencies like `rivershared` and `rivertype`, `go get` Go/toolchain there first, then work my way up the stack all the way up to the main project. I'm going to try and follow this up with some tooling to help make this easier for ourselves, and a build check that verifies in CI that nothing gets accidentally regressed as we make changes because this is _very_ easy to do accidentally. Fixes #520. [1] https://go.dev/doc/toolchain [2] https://go.dev/doc/toolchain#get
brandur
added a commit
that referenced
this issue
Aug 9, 2024
This one related to #520, in which it turns out that our Go 1.21 build step has actually been automatically upgrading itself to Go 1.22, so under the radar that we didn't notice. Here, leverage a Go "toolchain" to establish a preferred version of Go for the project, but keeping a `go` directive in `go.mod`s that's at the 1.21 lower bound that we're trying to support. The presence of a `toolchain` directive prevents `go mod tidy` from upgrading the `go` directive to the latest version of Go installed. I found the easiest way to add the toolchain directive to be with `go get` [2] like: go get [email protected] [email protected] Maintaining this correctly is going to be a little tricky. This is one of those classic Go features that kind of works, but various Go commands will perform all kinds of confusing behavior like stripping directives out of your file if there's anything even a tiny bit wrong, and with no explanation whatsoever. I found that to get this working I had to started with the "inner" dependencies like `rivershared` and `rivertype`, `go get` Go/toolchain there first, then work my way up the stack all the way up to the main project. I'm going to try and follow this up with some tooling to help make this easier for ourselves, and a build check that verifies in CI that nothing gets accidentally regressed as we make changes because this is _very_ easy to do accidentally. Fixes #520. [1] https://go.dev/doc/toolchain [2] https://go.dev/doc/toolchain#get
brandur
added a commit
that referenced
this issue
Aug 9, 2024
This one related to #520, in which it turns out that our Go 1.21 build step has actually been automatically upgrading itself to Go 1.22, so under the radar that we didn't notice. Here, leverage a Go "toolchain" to establish a preferred version of Go for the project, but keeping a `go` directive in `go.mod`s that's at the 1.21 lower bound that we're trying to support. The presence of a `toolchain` directive prevents `go mod tidy` from upgrading the `go` directive to the latest version of Go installed. I found the easiest way to add the toolchain directive to be with `go get` [2] like: go get [email protected] [email protected] Maintaining this correctly is going to be a little tricky. This is one of those classic Go features that kind of works, but various Go commands will perform all kinds of confusing behavior like stripping directives out of your file if there's anything even a tiny bit wrong, and with no explanation whatsoever. I found that to get this working I had to started with the "inner" dependencies like `rivershared` and `rivertype`, `go get` Go/toolchain there first, then work my way up the stack all the way up to the main project. I'm going to try and follow this up with some tooling to help make this easier for ourselves, and a build check that verifies in CI that nothing gets accidentally regressed as we make changes because this is _very_ easy to do accidentally. Fixes #520. [1] https://go.dev/doc/toolchain [2] https://go.dev/doc/toolchain#get
brandur
added a commit
that referenced
this issue
Aug 9, 2024
This one related to #520, in which it turns out that our Go 1.21 build step has actually been automatically upgrading itself to Go 1.22, so under the radar that we didn't notice. Here, leverage a Go "toolchain" to establish a preferred version of Go for the project, but keeping a `go` directive in `go.mod`s that's at the 1.21 lower bound that we're trying to support. The presence of a `toolchain` directive prevents `go mod tidy` from upgrading the `go` directive to the latest version of Go installed. I found the easiest way to add the toolchain directive to be with `go get` [2] like: go get [email protected] [email protected] Maintaining this correctly is going to be a little tricky. This is one of those classic Go features that kind of works, but various Go commands will perform all kinds of confusing behavior like stripping directives out of your file if there's anything even a tiny bit wrong, and with no explanation whatsoever. I found that to get this working I had to started with the "inner" dependencies like `rivershared` and `rivertype`, `go get` Go/toolchain there first, then work my way up the stack all the way up to the main project. I'm going to try and follow this up with some tooling to help make this easier for ourselves, and a build check that verifies in CI that nothing gets accidentally regressed as we make changes because this is _very_ easy to do accidentally. Fixes #520. [1] https://go.dev/doc/toolchain [2] https://go.dev/doc/toolchain#get
|
I think we got this figured out in #522, and will cut a release shortly. @rgalanakis Keep the quality of life problem reports coming. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I need to use a slightly older Docker base image that only has Go 1.22.3 available. I had to pin back to River 0.9, because River 0.10 on uses 1.22.5. Ideally it'd use 1.22.0 unless there is some compelling reason, so people stuck on older 1.22 versions do not need to pin to older versions.
Hopefully I'm not off-base with this suggestion- given Go language versioning rules, it seems like I should be able to ignore the patch version, but as of Go 1.21 I don't think that's possible. So River version 0.10 and newer is only compatible with Go versions 1.22.5 and higher, released July 2 2024. But please let me know if I'm misunderstanding the issue I'm having, I don't follow Go packaging closely so may have missed something.
The text was updated successfully, but these errors were encountered: