Standardize start of version string reported by clients

[bobsummerwill]

As exposed by http://ethernodes.org/, we have a lack of basic uniformity in our "agent version" strings.

I would like to propose that we add a RECOMMENDATION that all agents report the following three entries at the START of the version name, followed by whatever else makes sense.

Name/Version/OS/*

For example:

Geth/v1.3.3/darwin/go1.5.2
++eth/v0.9.41-ed7a8a35/Windows/Release/msvc/JIT
Ethereum(J)/v1.0.0/Linux/Dev/Java

See also ethereum/webthree-umbrella#128.

[tgerring]

👍

[wanderer]

:+1

[peterbitfly]

👍

[karalabe]

As discussed on reddit a while ago, I myself fully support this decision 👍

Geth itself usually follows this convention, but a user has the possibility to insert an extra meta field that we'd need to move to the end, but I think it's only reasonable. I would also suggest creating a wiki page on the main ethereum wiki with the both the "recommended" versioning schema as well as any extra details each implementation might have (e.g. for go, the 4th entry is the Go runtime).

[obscuren]

👎 I don't see the need to standardise (EDIT: or recommendation) on this level for the same reason I don't see the need to standardize the name of binaries or naming of archives.

I don't see what you'll gain by this other than a pretty naming scheme on a community website (no disrespect).

I believe clients should implement their naming however they like.

[karalabe]

I don't think the aim was to standardize, but rather to provide a guideline which would allow easier analysis tools to be written. The goal really is that if someone writes a tool that would like to interpret the contents of the version string, it should be fairly easy to get at least some barebone metadata out of it, before needing to write custom parsers.

[obscuren]

Standardization or recommendation, I do not see the need for it

[obscuren]

Additionally, versions, naming, etc should simply be a way too freely express certain parameters of a client. Recommending a standard (because that’s really what we’re doing here) actually takes away that certain freedom and forces you in to submission. I’m saying forces because it’s either you implemented and get X rewarded (in this case listed on a website) or you don’t and you don’t get rewarded.

[chfast]

I would rather see that as a suggestion in case as an client author you don't have your own preferences.

[obscuren]

I'd also like to point out that these strings are supposed to be human readable as opposed to computer interpretable (that's just secondary).

[karalabe]

This would be my suggestion, I wrote it up this morning, but we can discard it if we don't want to provide even this much: https://github.com/ethereum/wiki/wiki/Client-Version-Strings

[peterbitfly]

There is also a similar approach with the block extra field which identifies the block miner: https://github.com/ethereum/wiki/wiki/Default-Extra-Data-Standard

[obscuren]

@ppratscher That is and was required for frontier to determine which miner was potentially mining invalid blocks using what version. Those bytes are not meant as a human readable block, but indeed as a computer interpreted block (it's binary data).

[bobsummerwill]

@gavofyork said on Parity gitter channel ...
assuming / delimited fields, at present ethstats.net throws away the second field. not sure why, but this has lead to there being a general format of Name//Version/Architecture/Language-Version
i believe Geth and Parity are both conforment to that format
perhaps that would be a good place to begin? if not, perhaps first getting marian/ethstats.net to switch their format recognition would help things along