Added hardcoded weaver module version.

[mwhittaker]

Module Version

We want a weaver version command that prints out the weaver module version the weaver binary was built with, or failing that, the commit at which the binary was built. Unfortunately, both of these things are hard.

There is currently no nice way to automatically get the version of the main module in a go program 1. There is a way to get the git commit using debug.ReadBuildInfo() 2, but when go installing a binary, the version control information is stripped.

Browsing existing open source projects, it seems the standard practice is to hard code the module version in the code. This PR does that and updates the weaver version command to use it:

$ weaver version
weaver v0.17.0 linux/amd64

Other Versions

The weaver repo has two other versioned APIs: the deployer API version and the codegen version. Currently, the deployer API version is the latest module version where the deployer API changed (and the same for the codegen version).

We discussed offline the idea of replacing the three versions (module, deployer API, codegen) with just the module version. Then, we could write additional code to check version compatibility. Is codegen v0.17.3 incompatible with v0.12.0, for example?

When trying to implement this, however, I ran into some problems. For example, let's say a deployer is at version v0.10.0 and tries to deploy an app at version v0.12.0. Is deployer API version v0.12.0 compatible with version v0.10.0? Well, the deployer was written before v0.12.0 was even created, so it doesn't have a good way to know.

The codegen version is also tricky because it relies on some compiler tricks to prevent an app from compiling if it has code generated with a stale version of weaver generate. I'm not sure how to implement these tricks without hardcoding a codegen version.

Because of these challenges, I decided to stick with our current approach to versioning, for now at least. To clean things up a bit though, I moved all versioning related code to runtime/version.go. I also moved some code to the bin package because it felt more appropriate there. I also moved runtime/tool/version.go to internal/tool/version.go because it shouldn't be used outside the module.

[spetrovic77]

Just a thought, and tell me if this sounds crazy. Could all the new deployers read the compatibility information from the user binary, if it needs to? The way we read listeners and component graph.

[mwhittaker]

Just a thought, and tell me if this sounds crazy. Could all the new deployers read the compatibility information from the user binary, if it needs to? The way we read listeners and component graph.

I think that's an interesting idea! I'll think about it more and think about implementing it in a future PR.