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

[tgerring]

@cubedro

On Feb 29, 2016, at 11:11, Bob Summerwill notifications@github.com wrote:

@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

—
Reply to this email directly or view it on GitHub.

[cubedro]

Sure, I can make the changes to ethstats.net. I think I was discarding the second parameter to save space.

[karalabe]

@cubedro I'd wait for @obscuren to weigh in too. Let's not jump and change things that work for a proposal that wasn't accepted.

[cubedro]

👍

[fulldecent]

@Arachnid You nominated this as an "EIPs that should be merged". Can you please share your notes on that here? Is there an actual EIP here to discuss?

[Arachnid]

This pull request is referenced by #58, which has already been merged. As such, it needs to either be finalised and merged, or the dependency in the existing EIP needs to be removed.

[axic]

#58 seems to be this issue? :)

[Arachnid]

Sorry, I mean #211.

[axic]

Are you sure it is #211, I don't see any reference in there?

[Arachnid]

@axic eip211 is listed as replacing this eip.

[axic]

Replaces: 5/8

Oh, IIRC that was supposed to mean it replaces "EIP5" and "EIP8", but in fact it only supersedes EIP5 which was tracked as #8.

[Arachnid]

@axic ah, thanks. I'll fix that.

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.