Consider the implications of renaming the "uavcan" namespace into "cyphal"

[pavel.kirienko]

@scottdixon

I think this is a bit of a non-starter unless we can do this in a phased manner where both are supported for a time.

There are two aspects: renaming the DSDL namespace itself and renaming the registers.

The DSDL renaming can be done by copying all non-deprecated definitions from the uavcan namespace into cyphal with the appropriate changes to the documentation where the original namespace is referenced. All uavcan.* definitions will be made @deprecated immediately, with their complete removal deadline set somewhere in the future.

The standard register names will be updated from uavcan.* to cyphal.*. Nodes will be encouraged to support both to enhance compatibility with old tooling, but we don’t want to unnecessarily burden new applications with supporting the legacy register naming scheme, so uavcan.*-named registers will be optional, and the new cyphal.* pattern will take precedence.

The latter change will make new nodes incompatible with the existing tooling, such as Yakut and Yukon. This is easy to address at this stage as these are the main Cyphal tools and we can implement the necessary adjustments fairly easily. In particular, Yakut/Yukon will attempt to query cyphal.* registers first and only fall back to uavcan.* if none are found.

@lydiagh

This would require a lot of duplicated code, but what if we had a uavcan and a cyphal namespace in the public_regulated_data_types repo. That way, people who are still using UAVCAN can continue to use the uavcan namespace and people using Cyphal can use the cyphal namespace.

I think this is sensible as long as we make it clear that the uavcan namespace is deprecated and is on its way toward its inevitable EOL.

@aentinger

This strikes me as a dangerous half measure.

Indeed.