Added hardcoded weaver module version. #421
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Module Version
We want a
weaver version
command that prints out the weaver module version theweaver
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 whengo install
ing 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: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 thebin
package because it felt more appropriate there. I also movedruntime/tool/version.go
tointernal/tool/version.go
because it shouldn't be used outside the module.