Closed Abhishekvrshny closed 3 years ago
I think that this is not an issue because go.mod
has a pretty obvious directive — go 1.16
, that indicates the minimal required version to use the product.
The issue is that any breaking change should ideally go as a major release. Although, I understand that buf is still in pre-release, but backward compatibility is still good to have.
Hi! We'll discuss internally what we want to do about this, but as a workaround you should be able to use the pre-built releases for now: https://github.com/bufbuild/buf/releases/tag/v0.40.0. The installation instructions recommend using one of the binary releases.
This isn't a breaking change. Increasing the minimum required version to build a Golang library is something widely-done across the entire Golang community for the same major version.
We have never had a breaking change in buf
across all 57 beta releases, and do not intend to break this streak, and this change doesn't represent a breakage. This is a common action performed across all Golang libraries.
While this isn't applicable here directly, it follows in the same vein as SemVer-managed upgrades: increasing the minimum required minor version of a dependency is acceptable, for example bumping github.com/foo/bar
from 1.0
to 1.1
. Even further, changing any dependency for a library is acceptable with Golang modules, as go.mod
tracks this information and go
handles any required downloads.
However, even further than this buf
isn't actually a Golang library itself - it is just a binary you install. We recommend you install from the binaries. However, if you want to install from source, the minimum version to do so is now 1.16, the bumping of which is a common upgrade across the Golang community.