Skip to content

Better Versioning

Luke Champine requested to merge version into master

This change consolidates the various version numbers into one spot: build.Version. Well, mostly; the persist stuff is a work in progress. It also adds a /daemon/version API call.

The gateway is the test case for this new version management scheme. The idea is that in order to check that a version is compatible, you pass it to build.VersionCmp, along with a "minimum compatible version." As an example, when a connecting peer sends its version to the gateway, the gateway checks "is this version greater than v0.3.3?" by calling build.VersionCmp(remoteVersion, "0.3.3") > 0. If the check fails, the gateway refuses to connect.

This can be extended to the persist files in a similar fashion: they simply indicate the oldest version they are compatible with (i.e. the last version that changed the save format). This has not been implemented yet.

The downside of this is that we have to keep track of what is compatible with what. But that was sort of inevitable anyway. Basically, any time you alter a protocol -- consensus, peer negotiation, persist data -- you just have to remember to bump the "minimum acceptable version" to the current version. (Of course, now that we're launched, we should also maintain compatibility tools that can read the old formats and update them to the new format.)

I also found a hackish way to ensure that we don't build releases with the wrong version number. You can pass a flag to the Go linker that sets the value of an unset string variable. So we could add a special test that compares such a string to build.Version and fails if they are not equal. Then, in the Makefile, we alter the make xc target to run a special test that sets the string to the same version passed to goxc. This struck me as fairly ugly though, so I left it out of this PR.

Merge request reports