infra icon indicating copy to clipboard operation
infra copied to clipboard

maintain: change makefile to update local dev versions

Open pdevine opened this issue 1 year ago • 2 comments

Summary

The version cli/server when you're building with the dev build with the makefile is pegged at 0.14.4. This can be misleading and confusing if you're expecting the actual version (e.g. right now we're currently on 0.15.2).

This change snags the current appVersion from the helm chart (although we can snag it from somewhere else if/when we move the helm chart) and patches our binary with the updated version (instead of 0.14.4).

pdevine avatar Sep 22 '22 22:09 pdevine

I went ahead and set the version to 0.0.0. Setting the version to the current version is just going to go out of date the second we release another version of the product, so this should work "for now", although we definitely need a more permanent fix.

pdevine avatar Sep 23 '22 00:09 pdevine

Instead of these changes, I would rather see internal.Version set to a dummy value like 99.99.99999 to indicate a development version. This has a few benefits, the primary one being simplicity. Since the real version is injected during image and artifact builds, this value does nothing.

The only time this value has any effect is when image or artifacts are build locally, or during tests. By setting such a ridiculous value, it should be obvious to the user this is not a real version string. This version in particular should ensure all migrations are always run since it's (almost) always a higher semantic version.

The simplicity of this allows us to not mess with the Makefile, not mess with the Version in the code, and not worry about API migrations not being applied. We can actually remove code if the default Version is something like 99.99.99999.

I put the change I have in mind into https://github.com/infrahq/infra/pull/3294

mxyng avatar Sep 23 '22 00:09 mxyng

I really like the approach in #3294

When combined with go version -m ./infra (which gives us the git commit that was used to compile the binary) that seems like it should address the problem. We no longer have a misleading version when combined with go build, and we still have a way to check what version of the binary we are running.

dnephin avatar Sep 23 '22 22:09 dnephin

No longer necessary after #3294

mxyng avatar Sep 26 '22 20:09 mxyng