---
date: "2019-12-22T00:00:00Z"
cover: /img/maverick.jpg
published: false
tags:
- programming
- software development
- software engineering
- golang
- go
title: Go 1.13 Non-semantic Version Woes
---

The pathway to Go modules was a winding one and in the wake of its many pilgrims is a wasteland of projects that are no longer semantically versioned. As project owners, we can't be blamed for having not known what would be semantically valid in the future, so we chose versions that made sense at the time: long sha digests, timestamps, datestamps, base64-encoded haukus.

Whether your own package versions have yet to be updated, you depend on packages that have yet be updated, or you have a transitive dependency on packages that has yet to be updated: if you're on Go 1.13, semantically invalid package versions can be a righteous pain in the ass. Most of us are unaffected because the Go community has been relatively quick to conform to semantic versioning, but there are still plenty of packages that we depend upon that have yet to conform.

I recently found myself in such a scenario. The two most common `go mod` problems are

1. invalid pseudo-version: revision is longer than canonical
2. invalid pseudo-version: does not match version-control timestamp

Luckily both of these are easy to fix with `replace` in your `go.mod`; no upstream re-tagging/versioning necessary. For example, the following package on Github has no semantically valid version tags available:

To solve (1.), the long-form of the sha digest can be truncated as follows:
> replace github.com/dependencyowner/dependencyname => dependencyowner/dependencyname  v0.0.0-20160803014805-c0a249674b73

To solve (2.), the timestamp can be removed from the pseudo-version entirely as follows:
> replace github.com/dependencyowner/dependencyname => dependencyowner/dependencyname  c0a249674b73

While I do encourage everyone to fix upstream package versions to keep the Go ecosystem healthy -- sometimes you just need to get stuff done.

I hope this helps someone from wasting as much time on this problem as I did. Cheers.
