Only upgrade go version in genmod, don't downgrade #1418
Conversation
dmathieu
force-pushed
the
genmod-go-version
branch
from
6b6a19f to
f134a1e
Compare
dmathieu
force-pushed
the
genmod-go-version
branch
from
f134a1e to
a88e449
Compare
| @@ -138,7 +139,7 @@ func updateModule(dir string, gomod *GoMod, modules map[string]*GoMod) error { | |||
| "-require", require.Path + "@" + *versionFlag, | |||
| "-replace", require.Path + "=" + relDir, | |||
| } | |||
| if *goVersionFlag != "" { | |||
| if *goVersionFlag != "" && semver.Compare("v"+*goVersionFlag, "v"+gomod.Go) == 1 { | |||
There was a problem hiding this comment.
I am not sure if this would be acceptable for all cases since it might break the compatibility of agents if go.mod for a specific module is unintentionally upgraded. @axw can probably clarify this.
Alternatively, we can add another option to exclude certain modules and execute 2 separate commands in the update-modules (might be more of a hack as the list might grow).
There was a problem hiding this comment.
If go.mod is unintentionally upgraded, wouldn't PR reviews be there to prevent that?
There was a problem hiding this comment.
I think it's fine releasing new modules with a version greater than the agent's minimum, just not the other way around. If the version of a module is updated after release such that compatibility is broken, I would consider that a bug that we would fix by reverting.
dmathieu
force-pushed
the
genmod-go-version
branch
from
28aa96e to
ad2ae84
Compare
We have some modules (such as apmotel) that don't support all the versions we provide support for.
For example, OpenTelemetry follows the go release policy, so versions lower than 1.19 aren't supported, and generics are used.
This means we can't build that module on go 1.15, and can't run
make update-modules.With this change, we will try to upgrade the go version if it's lower than the one specified. However, if it's higher, we consider that to be on purpose, and don't change it.