"Normalize" eth's version-identification with the next release

[bobsummerwill]

We should probably "Normalize" eth's version-identification with the next release, so that the results shown in http://ethernodes.org/ and other crawlers group the C++ clients better.

At the time of writing, ethernodes shows the following stats:

• AlethOne - 19 nodes, all with broken version strings, like this:
  • AlethOne/v1.0.0/ETH_BUILD_TYPE/ETH_BUILD_PLATFORM
  • Except one which is AlethOne/v1.1.1/ETH_BUILD_TYPE/ETH_BUILD_PLATFORM.
• AlethZero - 12 nodes, mainly with broken version strings, like this:
  • AlethZero/v1.0.0/ETH_BUILD_TYPE/ETH_BUILD_PLATFORM
  • AlethZero/v1.1.1/ETH_BUILD_TYPE/ETH_BUILD_PLATFORM
  • AlethZero/v1.0rc2/ETH_BUILD_TYPE/ETH_BUILD_PLATFORM
  • And some non-broken strings ONLY on Windows - AlethZero/v0.9.41/Release/Windows/msvc/JIT
• ++eth - 42 nodes, with a wide variety of version strings, many broken:
  • ++eth-v0.9.41-cb61d09d//Release-Windows/msvc/JIT
  • ++eth-v0.9.41-cb61d09d/Eggplant//Release-Windows/msvc/JIT
  • ++eth-v0.9.41-ed7a8a35//Release-Windows/msvc/JIT
  • ++eth-v1.0.0-81690335//Release-Windows/msvc/JIT
  • ++eth-v1.0.0-ad91cc9e//Release-Windows/msvc/JIT
  • ++eth-v1.0.0-0//Release-Linux/g++/int
  • ++eth-v1.1.0-0/CryptoComposite//Release-Linux/g++/int
  • ++eth-v1.1.0-4b4d955d//Release-Windows/msvc/JIT
  • ++eth-v1.1.1-377f1a37//Release-Darwin/unknown/int
  • ++eth-v1.1.1-377f1a37//RelWithDebInfo-Darwin/unknown/JIT
  • ++eth-v1.1.1-ae31b9f7*//Debug-Linux/g++/JIT
  • ++eth-v1.1.1-0//Release-Linux/g++/int
  • ++eth-v1.1.1-0/nullvoid//Release-Linux/g++/int

[bobsummerwill]

Where is this version defined for ++eth, and what do the elements correspond to?
What is the second element, which nearly always seems to be blank?

[bobsummerwill]

@ppratscher - See above.

Also ... for some reason, the nodes with version starting with "++eth-v1.1.1-377f1a37" are currently showing as "v1.1.1-377f1a37" on the main http://ethernodes.org/network/1 page. Perhaps your parsing making some assumptions about the number of dash-separated elements?

[bobsummerwill]

Some examples of Geth versioning, by way of contrast, and which I think it makes sense for us to copy:

• Geth/v1.3.3/darwin/go1.5.2
• Geth/v1.3.3/linux/go1.5.1
• Geth/v1.3.3/windows/go1.5.1
• Geth/v1.3.3-c541b38f/linux/go1.5.2
• Geth/v1.4.0-unstable/linux/go1.5.1

And look at this brave soul!

• Geth/v1.4.0-unstable-5945a333/android/go1.6beta1

[bobsummerwill]

And Ethereum(J)'s is the "wrong way around":

• Ethereum(J)/v1.0.0/Dev/Linux/Java

It would be very useful to have a standard triple at the start of ALL client version strings:

Name/Version/OS/*

[peterbitfly]

@bobsummerwill ethernodes.org assumes the versioning scheme that geth uses (as it is the most commonly used client)

I appreciate any effort to harmonize the client id among all ethereum implementations. The Name/Version/OS/* version looks good to me.

[smartbitcoin]

Does this approach make sense since the ethereum is opensource? in case end-user have their own modified version, how can you force a version standard?

[bobsummerwill]

You can't force the standard, no, @smartbitcoin.
I'm just talking about a voluntary alignment of versioning between the main clients, just to make it easier to analyze.

[chfast]

This might be a good candidate for EIP: https://github.com/ethereum/EIPs/issues.

[bobsummerwill]

Done! Created the following EIP - ethereum/EIPs#58.