We don’t yet have a well-defined date for its EOL, but you are correct in your view that new applications should be using v1. The first stage of the v0-v1 transition will begin in 2020Q1, as explained in UAVCAN 2019 roadmap. This is when we are going to update the website and all GitHub repositories to point to v1 by default. For the benefit of existing deployments, v0 will still be available and maintained for a few more years at least.
This forum is the right place for such discussions. If you have a piece of feedback or a proposal, please start a new topic in Development & Maintenance - OpenCyphal Forum.
V1 does not and will not include any application-specific data types. Instead, they are relegated to the regulated namespace, which is outside of the scope of the Specification. Eventually, we will use that to define a set of application-specific profiles, but they are not going to be part of the core specification (think of it like USB device classes or CANopen profiles).
You can learn more about this decision here:
- UAVCAN V1 FAQ s
- Data type regulation policy and membership fees
- UAVCAN: a highly dependable publish-subscribe protocol for real-time intravehicular networking
- Chapter 2 of the Specification.
From the other thread:
All regulated data types will use SI, hence radian/second instead of RPM. We are unlikely to accept a data type using RPM because it does not follow the application recommendations outlined in the Specification and in the public regulated data types repository.
We can certainly add a new namespace for your company if it does not replicate the functionality available under existing namespaces and it follows the data type design recommendations. If you would like to go ahead, I recommend you to start a new thread in /c/dev with your proposal.