Versioning scheme

[SyntheticBird45]

What is the versioning scheme of Cuprate ? I see three options:

• Semantic Versioning: MAJOR.MINOR.PATCH with first release of Cuprate being 1.0.0
• Semantic Versioning: MAJOR.MINOR.PATCH but following monerod versioning. So Cuprate first version will likely be 18.3.1
• 0ver versioning: 0.MINOR.PATCH. I don't see any reason to use this.

Pros of following monerod versioning:

• Same version means it is compatible by network consensus.
• Easier for people to understand the latest version Cons of following monerod versioning:
• Doesn't make a lot of sense to come out with an Alpha software at version 18.
• How do we name our fixes release ? We shouldn't be limited by monerod number of updates. Maybe MAJOR.MINOR.PATCH-N (eg. 18.3.1-5)

[Boog900]

For the cuprated binary I would be for the first option. However I think the crates that make up Cuprate should follow their own versioning.

For what I think the rules should be for the Cuprate binary should be, I think the MAJOR field should indicate a hf, so when we become stable the major field should only be incremented on hf before that I think versioning should have less defined rule.

[SyntheticBird45]

So following what you proposed first version of cuprated will be 18.0.1. The scheme is : HARDFORK.UPDATE.PATCH. with UPDATE being an API change, and PATCH being fixes.

[Boog900]

No just that the major version will only be increased on hf so first version will still be 1 but will only go to 2 when/ if there is a hardfork.