The change from v3.4.0 to v3.5.0 is the first version where the Go
module had a real version associated with it. This also includes the
first of two module import path changes sops went through to on its way
to the current v3.9.1 version. This one is from go.mozilla.org/sops to
go.mozilla.org/sops/v3.
v3.5.0 dates back 4 years, but an update directly to 3.9.1 was around
500,000 new lines of code being added at once. Partially, because in
v3.8.0, the sops maintainers changed the module path again from
go.mozilla.org/sops/v3 to github.com/getsops/sops/v3.
There's good reason to do that larger update (mostly, it's holding on to
very old versions of other dependencies), but we choose to break that
upgrade across multiple bumps for reviewer ease.
My current plan is to bump us to v3.5.0, then to v3.7.3 (the last
version before the second getsops import path change), and then to
v3.9.1.
I could be told we should just do the one big leap to avoid the two
different import path changes.
The change from v3.4.0 to v3.5.0 is the first version where the Go module had a real version associated with it. This also includes the first of two module import path changes sops went through to on its way to the current v3.9.1 version. This one is from
go.mozilla.org/sopstogo.mozilla.org/sops/v3.v3.5.0 dates back 4 years, but an update directly to 3.9.1 was around 500,000 new lines of code being added at once. Partially, because in v3.8.0, the sops maintainers changed the module path again from
go.mozilla.org/sops/v3togithub.com/getsops/sops/v3.There's good reason to do that larger update (mostly, it's holding on to very old versions of other dependencies), but we choose to break that upgrade across multiple bumps for reviewer ease.
My current plan is to bump us to v3.5.0, then to v3.7.3 (the last version before the second
getsopsimport path change), and then to v3.9.1.I could be told we should just do the one big leap to avoid the two different import path changes.