feat: Add ability to check DefraDB CLI version.

[shahzadlone]

Adds the ability to check DefraDB's latest release version.
Resolves #259

Usage:
  defradb version [flags]

Flags:
  -f, --format string   The version's format can be one of: 'short', 'json'

Example [default]:

>> $ defradb version

Example [short flag]:

>> $ defradb version -f short

0.2.1

Example [json flag]:

>> $ defradb version --format json

{"tag":"0.2.1","commit":"e4328e0","date":"2022-03-07T00:12:07Z"}

[AndrewSisley]

Looks really nice :) I do question slightly as to whether it is worth an extra 3rd party dependency though - but will trust your decision on that

[shahzadlone]

Looks really nice :) I do question slightly as to whether it is worth an extra 3rd party dependency though - but will trust your decision on that

Are you referring to color support (fatih/color)?

[shahzadlone]

There is actually one thing we have to have a discussion on. The commit hash that is returned for the version probably shouldn't be hardcoded. Because the releasing tag commit (final commit) will not know it's own hash in advance to place in the commit (as commit hashes dependent on the time the commit happened at and who made the commit). The other approach might be to put the hash of one commit before the released tag.

[AndrewSisley]

Looks really nice :) I do question slightly as to whether it is worth an extra 3rd party dependency though - but will trust your decision on that

Are you referring to color support (fatih/color)?

Yes

[orpheuslummis]

LGTM :)

I want to add that I'll provide an update to the implementation as part the CLI overhaul I'm working on to include things like

• top-level version package to have default version information of potentially multiple components
• Makefile -> git describe -> build tags defining defradb version variable
• as part of the configuration overhaul i'm introducing a --no-color which will conditionally turn off the coloring, and an output global flag (text, json) to globally decide on the default output type used

I think the added color dependency looks fine - convenient, popular/supported, probably not heavy

[jsimnz]

Is this worth pursuing if @orpheuslummis plans on re-implementing it as the CLI overhaul.

My approach for this would be a dedicated version package, whose vars can be set at build time using LDFlags, like so:

https://github.com/tendermint/tendermint/blob/851c0dc4f3088723c724cb01c4877ee78c3d6ffc/Makefile#L14

and

https://github.com/tendermint/tendermint/blob/851c0dc4f3088723c724cb01c4877ee78c3d6ffc/version/version.go#L6

[shahzadlone]

Is this worth pursuing if @orpheuslummis plans on re-implementing it as the CLI overhaul.
My approach for this would be a dedicated version package, whose vars can be set at build time using LDFlags, like so:
https://github.com/tendermint/tendermint/blob/851c0dc4f3088723c724cb01c4877ee78c3d6ffc/Makefile#L14
and
https://github.com/tendermint/tendermint/blob/851c0dc4f3088723c724cb01c4877ee78c3d6ffc/version/version.go#L6

I have added these to #349
Inaddition to this approach I have added another approach in #349 which golangci-lint uses they also use ld build flags however through goreleaser which I think will be a good approach once we have goreleaser setup.

For now as we already have users that are starting to use Defra so I think that merging this is fine as it offers them (those building from source) a quick way to see they are indeed on v0.2.1. This should be a fairly easy refactor / cleanup todo for @orpheuslummis when they decide on goreleaser or tendermint like approach using ld flags. I also see the CLI overhaul also has 10 total subtasks so until the version stuff gets implemented this can still be usable. The LDFlags approach from golangci-lint can actually build on top of this code quite nicely. For completeness here is the future approach from golangci-lint which uses LDFlags through goreleaser (also posted these in #349):

• Here is golangci-lints goreleaser.yaml file: https://github.com/golangci/golangci-lint/blob/master/.goreleaser.yml
• They have a line there as follows for ldflags:

 ldflags: -s -w -X main.version={{.Version}} -X main.commit={{.ShortCommit}} -X main.date={{.Date}}

• Then in their cmd/golangci-lint/main.go file : https://github.com/golangci/golangci-lint/blob/master/cmd/golangci-lint/main.go
• They have this structure that gets populated on build by goreleaser:

var (
	// Populated by goreleaser during build
	version = "master"
	commit  = "?"
	date    = ""
)

• Which then through their Executor makes it to here: https://github.com/golangci/golangci-lint/blob/master/pkg/commands/version.go
• Which connects to the cobra package like our current implementation and so it can be built on top of our existing implementation.

Unless there is strong opposition to merging this in, I would say it's okay to merge it for now gives the feature quickly for people using and can be built on top of (depending on which ld flag approach is picked)

[jsimnz]

Is this worth pursuing if @orpheuslummis plans on re-implementing it as the CLI overhaul.
My approach for this would be a dedicated version package, whose vars can be set at build time using LDFlags, like so:
https://github.com/tendermint/tendermint/blob/851c0dc4f3088723c724cb01c4877ee78c3d6ffc/Makefile#L14
and
https://github.com/tendermint/tendermint/blob/851c0dc4f3088723c724cb01c4877ee78c3d6ffc/version/version.go#L6

I have added these to #349 Inaddition to this approach I have added another approach in #349 which golangci-lint uses they also use ld build flags however through goreleaser which I think will be a good approach once we have goreleaser setup.

For now as we already have users that are starting to use Defra so I think that merging this is fine as it offers them (those building from source) a quick way to see they are indeed on v0.2.1. This should be a fairly easy refactor / cleanup todo for @orpheuslummis when they decide on goreleaser or tendermint like approach using ld flags. I also see the CLI overhaul also has 10 total subtasks so until the version stuff gets implemented this can still be usable. The LDFlags approach from golangci-lint can actually build on top of this code quite nicely. For completeness here is the future approach from golangci-lint which uses LDFlags through goreleaser (also posted these in #349):

• Here is golangci-lints goreleaser.yaml file: https://github.com/golangci/golangci-lint/blob/master/.goreleaser.yml
• They have a line there as follows for ldflags:

 ldflags: -s -w -X main.version={{.Version}} -X main.commit={{.ShortCommit}} -X main.date={{.Date}}

• Then in their cmd/golangci-lint/main.go file : https://github.com/golangci/golangci-lint/blob/master/cmd/golangci-lint/main.go
• They have this structure that gets populated on build by goreleaser:

var (
	// Populated by goreleaser during build
	version = "master"
	commit  = "?"
	date    = ""
)

• Which then through their Executor makes it to here: https://github.com/golangci/golangci-lint/blob/master/pkg/commands/version.go
• Which connects to the cobra package like our current implementation and so it can be built on top of our existing implementation.

Unless there is strong opposition to merging this in, I would say it's okay to merge it for now gives the feature quickly for people using and can be built on top of (depending on which ld flag approach is picked)

Agree perfectly with this assessment! Lets merge this now as a short term and rework as we need/arrive with the CLI refactor.

[jsimnz]

LGTM