how to handle the difference in versioning a lib and its various binaries about coding

[odeke-em]

Thank you @zramsay! Paging the rest of the crew @adrianbrink @ebuchman @ethanfrey.

@zramsay in regards to your proposition

IMO we should have the version/version.go used by a package and all its binaries (i.e. same version). the Makefile can append a commit if we want to get fancy

In deed, I agree, and we currently have version/version.go populate the major, minor and plain versions https://github.com/tendermint/basecoin/blob/unstable/version/version.go#L1-L8

and then whatever tool can populate their specific commit hash as we've seen https://github.com/tendermint/basecoin/pull/230 and https://github.com/tendermint/basecoin/pull/223 do.

[adrianbrink]

Ethermint currently does that.

[zramsay]

ok great. Ideally each ethermint, basecoin, and tendermint (and other repos) all do it exactly the same way. That's what I'm aiming for with this repo. Same with cosmos/ethermint-archive#196, which is really an issue for this repo, since it applies to all repos

[adrianbrink]

The issue on ethermint is more to remind me to actually integrate that into the CI process. If you check the Makefile you can see which linters I am running: https://github.com/tendermint/ethermint/blob/develop/Makefile#L69 .

Essentially all of them besides linelength and I would recommend that we are using that as the standard. The problem so will be that initially it will be a ton of work to update 25,000 lines in tendermint core so that it builds against the linters.

[adrianbrink]

I've raised the issue on tendermint core as well: tendermint/tendermint#616

[ethanfrey]

I just updated the makefile in cosmos Sdk to reflect repo versión and git commit in all binaries

[ebuchman]

What if a repo has multiple binaries? Do they all share a version? What if you make a breaking change to the lib but not that binary? What if you make a breaking change to the binary but not the lib? All share one version ?