Closed andig closed 3 years ago
In the Go ecosystem (as opposed to Java), staying close to the latest version of the Go runtime is the standard. I know of a few libraries that fully support the last 1-2 Go versions.
In this particular case, the previous version (at Go 1.13) still exists and can be pinned. The reason for this move is that we are preparing to upgrade everything in our internal infrastructure up to Go 1.17 to take advantage of how Go manages modules and dependencies.
If you require a lesser Go runtime than 1.17, please use the previous version of assertions
.
In the Go ecosystem (as opposed to Java), staying close to the latest version of the Go runtime is the standard.
I would disagree. Many popular foundation libraries are supporting Go 1.13 or even earlier.
The reason for this move is that we are preparing to upgrade everything in our internal infrastructure up to Go 1.17 to take advantage of how Go manages modules and dependencies.
Go modules have been well-supported since at least Go 1.15 (I believe even Go 1.14). There is nothing in Go 1.17 that I'm aware of that would require such a change.
Seems this module does not require go 1.17. It would be nice to lower the required version. E.g. 1.16 is very popular as it brought
embed
support. Not sure why 1.17 should be required?