Specify versioning for the standard.

[thirtytwobits]

Before the first breaking change is introduced to the standard we should call the current master branch something like 1.0 or 0.5 and cut a release branch with that name (e.g. release/1.0). The version of the standard should also be prominently featured in the text of the specification.

We should be very crisp where any breaking change is introduced in the standard and in all projects that follow this standard. Putting forward a consistent versioning scheme seems like the first step in maintaining this clarity. All reference implementations (e.g. libuavcan) should also provide indications of the standard version they implement which may include maintaining release branches.

[pavel-kirienko]

I support the idea of moving the spec to PDF - they are made to be versioned, unlike websites. I should find some time to propose certain changes soon.

[thirtytwobits]

So, what do we call the current version. 1.0? 0.5? Bob?

[kjetilkjeka]

Bob is nice....

My suggestion is that we release the current version as version 0 (alternatively version 0.1). I don't think it need to correspond with the version number of libuavcan. But it would be nice if it corresponded with the newly introduced version bit.

Uavcan.rs will be supporting both versions to some extent. (Supporting version 0 where the version bit is used, or where rightmost priority bit happens to be 0). And if version 2 is ever released it will hopefully support version 2 in uavcan.rs version 1.x. it has the framing scheme (protocol version) as a config.

Furthermore, we should include the version bit change for the old protocol but be clear about it being a backward compatible deprecation in order to be compatible with the new protocol. More precicely, we should require the version bit to always be sent as 0, but be ignored on reception for version 0.

[thirtytwobits]

Okay. So concrete actions:

1. documentation on master should be updated to call itself "version 0"
2. version 0 should be amended with compatibility notes on the protocol versioning bit.
3. documentation in the new release 1.0 branch should be updated to call itself "version 1.0"

[kjetilkjeka]

documentation in the new release 1.0 branch should be updated to call itself "version 1.0"

We should probably for a while refer to it as "version 1.0-alpha" (or perhaps even 0.1).

---

We should also have a plan to avoid the following two things:

1. Stabilizing awfull choices unknowingly
2. Postponing stabilization indefinitely.

We could set a date 6-12 months after the protocol specification is settled and reference implementations updated. Before this date we do testing ourselves and encourage everyone else to do testing as well. We should actively encourage testers to share results and concerns. At the set date, we attempt to reach consensus wether we should stabilize or postpone the decision to another set date. Even if we decide to stabilize we should have a final comment period of ~4weeks where we can change the decision to postpone if we receive big concerns.

This way the set date will not be an absolute deadline but a goal to work against. If we decide to postpone this will be concious choice, and we will probably know what uncertanties we need investigate during the extra time.

[thirtytwobits]

(sorry, accidentally clicked the close button)

[pavel-kirienko]

I suggest to close this issue and migrate remaining questions to the discussion at OpenCyphal/specification#25.