lookout-sdk binary should expose SDK library version
The idea is that any client using lookout-sdk binary should be able to make sure that he uses the right binary, supporting his exact SDK library version.
As client already knows an SDK version he uses, it should be enough to just expose the SDK version that lookout-sdk binary was build across i.e though CLI of lookout-sdk version.
That way the client could check if it matches his desired version and fail fast, avoiding possible tricky gRPC compatibility errors at later runtime stages.
E.g. this would allow for caching lookout-sdk binary on CI and only downloading it from Github in case version does not match.
Motivated by discussion in https://github.com/src-d/style-analyzer/issues/95#issuecomment-418726078
I looked into this and it was not obvious how to proceed. From the src-d/lookout repository the only place to check the exact version of the src-d/lookout-sdk build we import is Gopkg.lock. As the lookout-sdk binary may be moved to the src-d/lookout-sdk repo maybe it's better to wait.
What do you think would be a better place to take this information from, after moving binary to src-d/lookout-sdk?
If we move the binary to the src-d/lookout-sdk repo, we can use the version & build set by the makefile from src-d/ci, right?
Another solution to this issue would be to export sdk version in go sdk, same as we do in python sdk: https://github.com/src-d/lookout-sdk/blob/master/python/lookout/sdk/init.py
Then lookout-tool can just print it.
@carlosms wdyt?
I don't like the idea of having another variable that we need to update manually before each release, but at this point that seems to be the most reasonable solution, yes.
I suggest having only 1 variable somewhere in the sdk. And update python&go sdk to read it.
I have tried a few solutions for having it only in one place and I don't like the result at all.
Let's pause this issue for now as we are returning to a discussion about moving the binary to another repo.
If at the and we still will want to have the version in source code and more than in 1 place, I would suggest to create make bump to take care of update.