Proposal for a New Build Numbering Scheme

[adrpan]

Hello,

I've noticed (and I'm sure I'm not the only one) that the current build version doesn't align with the protocol version. This creates unnecessary confusion; for example, a Casper Node build on the testnet with version 2.0.0-a7e4ff1 is actually a 2.0.1 version.

I'd like to propose a proper solution to this issue.

Proposal for a New Build Numbering Scheme
Currently, the build version syntax is as we've seen. My proposal is to replace this with ProtocolVersion-commitID. Using the example from above, this would become 2.0.1-a7e4ff1.

What would this small change achieve?

It would make it much easier to manage builds for a specific protocol version. Developers could modify and optimize the software within a single protocol version without confusion.

It would significantly reduce the current chaos and make versioning more intuitive for everyone.

Additional i have a question, why 2.0.1 for testnet = mainnet 2.0.0 and both has same build version? Or someone did mistake with publish version or i dont get it.

[mssteuer]

@sacherjj can you respond please?

[sacherjj]

Protocol version is a combination of a binary version and a network configuration. We attempt to keep these synchronized but they are not the same. Any change to network configuration requires a protocol version change. There is no reason to release a binary in this situation. It would in fact increase risk as this requires testing the new build.

What we have done is move the configuration files into the casper-node, to get configuration and binary tied together in one location. This will have versioning of configuration even if no casper-node changes occur. It will lead to more releases for possibly no binary change, but will hopefully help with confusion. The configuration files of the live network will still have slight changes for activation point and known addresses, but will be kept as close as possible.