Praveen Arimbrathodiyil <praveen@onenetbeyond.org> writes: > On 14/2/24 8:03 AM, Mathias Gibbens wrote: >> On Mon, 2024-02-12 at 19:08 +0530, Praveen Arimbrathodiyil wrote: >>> Do we assume SemVer.org compliance for modules with >= 1.0 versions? >>> >>> ie, should we assume things will break for every minor updates as >>> well? >> I've personally found it to be a very mixed bag -- some >> developers do >> try to follow SemVer, while others don't. At best, the version number >> can be a hint that there might be breaking changes. I always use `ratt` >> to build reverse dependencies in main locally before I upload any >> updated golang package. > > But isn't this adding too high a barrier on ourselves if every minor > update has to be treated like a breaking change ? (we could have an > exception list for sensitive or known bad upstreams like grpc). Trusting version numbers isn't sufficient. There was a nice presentation about tooling to detect these issues in the Rust ecosystem, and they could be extended for Go too: https://fosdem.org/2024/schedule/event/fosdem-2024-2682-semver-in-the-rust-ecosystem-breakage-tooling-and-edge-cases/ These problems were common for C libraries many years ago (and still is, but more rare) and most upstream C projects eventually learned to do this properly, but versioning in the Rust/Go ecosystems seems less rigid including proper adhearance to semver. I don't think there is any way around rebuilding all reverse dependencies whenever a golang-*-dev package is updated to a new version, so +1 on ratt or similar solutions. I found ratt challenging to setup, so I prefer using GitLab pipelines because all build logs are publicly available. /Simon
Attachment:
signature.asc
Description: PGP signature