41–50 of 64 posts
This just got me. Datadog decided that they only support the current and last major versions of Go. So, 1.26 and 1.25. But in my cause we're still on 1.24.13 which was released by the Go team less than two months ago. Datadog won't be getting a renewal from us.
What hacks are you relying on that makes it impossible to upgrade to 1.25 or even 1.26?
This just got me. Datadog decided that they only support the current and last major versions of Go. So, 1.26 and 1.25. But in my cause we're still on 1.24.13 which was released by the Go team less than two months ago. Datadog won't be getting a renewal from us.
Yes, and then one week later the entire 1.24 branch entered EOL: https://endoflife.date/go
>My package really does depend on the latest patch release! > Even in the event that your packages code is only correct with a specific patch release, I still think its wrong to put that version in the go directive unless it cannot be compiled with any other version. I'm not a go user, but this strikes me as an over-reaction. If your code is only correct with a specific patch release, then it really is your business…
I can admit that part was maybe a bit extreme :) fortunately in practice this would be a pretty rare situation IME due to how compatible Go is across versions. (Blog author)
Same situation in Rust crates, AIUI.
In go, `go mod init` and `go get go@latest` (both recommended commands), both set a 'go ' stanzas. In go, you _must_ set a minimum required version. If you type 'cargo init', you will get 'edition = "2024"', but no 'rust-version'. The situation is different because rust does not require a 'rust-version' in Cargo.toml, and in practice most crates do not have one, while in go it is required you specify a minimum versio…
> The version is the minimum version your project can be compiled with. No, it's the minimum version my project is tested with. > This means when you put a version like 1.25.7, you are deciding for everyone that imports you, transitively or directly, that they MUST be on Go 1.25.7+ to compile their project. That is fine. This isn't Python or Java, you have no reason to ever be more than one version behind the current…
I think the directive could have been named better though, maybe something like min_version.
>My package really does depend on the latest patch release! > Even in the event that your packages code is only correct with a specific patch release, I still think its wrong to put that version in the go directive unless it cannot be compiled with any other version. I'm not a go user, but this strikes me as an over-reaction. If your code is only correct with a specific patch release, then it really is your business…
I can admit that part was maybe a bit extreme :) fortunately in practice this would be a pretty rare situation IME due to how compatible Go is across versions. (Blog author)
Maybe that’s why some author do not bother and put the version they are using (though I do agree it is a bad practice indeed).
Does go support automatic testing of all version from X..Y?
Otherwise I don't see it being usable to define another version than the one I'm testing with in my go.mod