Define versioning scheme

[cornelius]

The software needs to be versioned and we need to agree on a scheme how to do that. While it's fun to debate the millions of possible schemes we should not overthink this and come to a practical solution.

It probably is helpful if the version expresses compatibility expectations in some way so users can tell from the version number what they need to do when updating, e.g. using the patch level to indicate a compatible change which is safe to upgrade, the minor version for new features which keep compatibility, and the major version to indicate breaking changes.

There are various ways how compatibility can be broken, e.g. protocol changes, configuration changes. What is most important to consider for the user here?

[scravy]

Another thing which I think we should talk about and finalize in an ADR is how we want to deal with soft forks, hard forks, etc. That is also the ultimate versioning.

There are BIPs about versioning and the like in bitcoin:

• https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki

Also there are more strings attached. As we are starting over we do not have any needs for all the checks and feature negotiations in the protocol which we want to always include by default. We have a good change to get rid of some legacy stuff which we don't need to carry around.

• Remove mining/fee related code / rpc commands unit-e#16
• clean up bitcoin protocol technical debt which requires hardfork otherwise unit-e#17

An interesting discussion by bitcoin about breaking user space and to what extent to keep compatibility in RPC commands.

• Breaking User Space bitcoin/bitcoin#14363

There's the following versioning / interface items IMHO:

• RPC Interface
• ZMQ Interface
• P2P Interface
• Blockchain Protocol / Layout
• BIP activation checkpoints
• Internal API
• what to do with libbitcoinconsensus

Regarding P2P interface and blockchain version bits I'd vote for starting over. As for versioning in general, as long as the network goes permissioned I think we can go 0.x, once we open to the public we should go 1.x. I realize that bitcoin is still 0.x, but come on, in reality everybody thinks about "bitcoin 16", "bitcoin 17" etc

[cornelius]

One more aspect is if we want to reflect the upstream version somehow in our versioning scheme.

[Gnappuraz]

@cornelius I'd say we want to mention it in the changelog whenever we merge from upstream but I would not tight ourselves to their versioning, we are our own project at the end and even if we take huge contributions from bitcoin we still wanna retain independence and flexibility to arbitrarily deviate from it.

[mergeable]

There has not been any activity in the past month. Is there anything to follow-up?

[mergeable]

There has not been any activity in the past month. Is there anything to follow-up?

[mergeable]

There has not been any activity in the past 10 days. Is this still active?