iroh --version

[faassen]

Have an iroh version command that does something sensible.

Currently it reports the version of the iroh-ctl crate. It makes sense that we report on this somewhere given that it can be useful information debugging, but it's not quite what ipfs version seems to do.

ipfs version shows the version of the kubo release itself. We could show the version of the iroh release. Should we base this off some Rust crate? Which one?

ipfs version also can be given a flag to get the commit hash, though in my case it just displays the release version, not a commit hash.

ipfs version also can be given a flag to get the repo version. What is a "repo version" and do we want that?

It supports an all option which does this:

$ ipfs version --all
Kubo version: 0.15.0
Repo version: 12
System version: amd64/linux
Golang version: go1.18.5

It reveals a system version and golang version too.

Then there's a deps subcommand which shows all the go dependencies, which I suggest we definitely not implement in Iroh.

A difference we have is that we have iroh cloud and iroh one and may want to see this too.

Then there's some overlap with iroh id, which also reports on version information:

	"AgentVersion": "kubo/0.15.0/desktop",
	"ProtocolVersion": "ipfs/0.1.0",
	"Protocols": [
		"/ipfs/bitswap",
		"/ipfs/bitswap/1.0.0",
		"/ipfs/bitswap/1.1.0",
		"/ipfs/bitswap/1.2.0",
		"/ipfs/id/1.0.0",
		"/ipfs/id/push/1.0.0",
		"/ipfs/lan/kad/1.0.0",
		"/ipfs/ping/1.0.0",
		"/libp2p/autonat/1.0.0",
		"/libp2p/circuit/relay/0.1.0",
		"/libp2p/circuit/relay/0.2.0/stop",
		"/libp2p/dcutr",
		"/p2p/id/delta/1.0.0",
		"/x/"
	]

Is there really a need for a top-level version command? Would it make sense to roll all of this into a ipfs id command instead?

[faassen]

Conclusion from the meeting: we have a -v or --version flag which reports the version of the binary. For iroh-one this is the version of iroh-one. For a future iroh-ctl command we report that.

[faassen]

I realized that -v is often also used for --verbose. Do we anticipate a verbose mode in the future? @dignifiedquire wants to avoid the situation where -v is verbose but --version is version. @b5, what do you think?

[faassen]

I figured other projects have a similar ambiguity for -v. Here's how mkfs deals with this:

    -V, --version

    Display version information and exit. (Option -V will display version information only when it is the only parameter, otherwise it will work as --verbose.)

Not an ideal way to handle the ambiguity...

Ah, I found an issue for cargo itself, probably a better guide:

rust-lang/cargo#117

Wouldn't be a bad idea to follow cargo in this:

 -V, --version               Print version info and exit
 -v, --verbose               Use verbose output (-vv very verbose/build.rs output)

If I run cargo -V I see:

cargo 1.63.0 (fd9c4297c 2022-07-01)

and if I run cargo -v by itself I see just its help text, which makes sense as I didn't issue any actual commands.

[faassen]

Note that this is only for the version of the CLI tool, not the version of anything else like iroh-one or iroh-cloud nodes. Again the analogy with cargo holds up well - we see the version for cargo, not rustc or whatever. (I just checked and rustc has the same flags too, so they must have conformed to this convention too some time after the writing of that cargo issue)

[dignifiedquire]

The convention from cargo sounds good to me, lets go with that 👍

[faassen]

It turns out clap does this by default without having to implement anything, so definitely going with that. :)

[faassen]

One drawback of the default implementation is that you get this answer:

$ iroh --version
iroh-ctl 0.1.0

and not iroh 0.1.0. I'm not entirely sure that's good or not, as iroh is a bit broad.

[dignifiedquire]

We should either rename the crate to iroh, or the binary to iroh-ctl. Otherwise we will create way too much confusion.

[b5]

Weighing in with my product hat on, the crate and the binary should both be called iroh, because iroh is the API. Iroh the product is a well-designed API to an efficient IPFS implementation.

[b5]

ok, we've made a decision on the crate organization & CLI binary name. See #153. All that's left is to merge the actual version flag

[faassen]

The version flag should work automagically once we do the renaming.