Erik Jaegervall (Jägervall)

I like the idea, but some thoughts: - Do we want the "final" identifier to be a string or a uint? It would be no problem for the Year-example above...

@sophokles73 - for transport purposes I believe you are correct, but if we want to use the identifier also for backend purposes it might be relevant. Like if a server...

_Warning - very long comment! Feedback if this would be a reasonable approach is welcome!_ I came up with a possible idea for managing unique identifiers and handling version control....

I would say that VSS as of today consist of three parts: - Semantics of how to define signals in "vspec-format",as defined in the documentation in this repo and visible...

I am not sure if I fully understand the context of the issue. We do not have `Vehicle.Timeincurrentrip` in the standard catalog. We have some trip-related data at https://github.com/COVESA/vehicle_signal_specification/blob/master/spec/Vehicle/Vehicle.vspec#L220

That would be doable, it seems quite similar to what the Eclipse Kuksa project is doing when providing metadata fro CAN/DBC to VSS mapping, see https://github.com/eclipse-kuksa/kuksa-can-provider/blob/main/mapping/README.md. But VSS/VSS-tools only help...

Deprecation works good for changes like: - Renaming a signal (Copy the old and rename it, mark the old as deprecated) - Removing a signal (Just mark it as deprecated)...

Based on the discussion on the VSS meeting earlier this week I would say that changing unit from `km/h` to `m/s` is a semantic change, i.e. nothing that we can...

I agree on the comments from Sebastian above, but we should possibly discuss branch-naming. As of today we typically create a branch `release/X.Y` when we release something but we have...

Meeting discussion: - Sebastian: Likely sufficient to support "current" and "next" release - If someone wants to support an older version it is OK, but that is not the responsibility...