-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding VSS 4.1 #2
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to write that we not fully tested it yet but it should work. we can remove this later.
vss/README.md
Outdated
@@ -9,6 +9,7 @@ In addition older versions may be supported. This folder contains copies of all | |||
|
|||
## Supported VSS versions | |||
|
|||
* [VSS 4.1](https://github.com/COVESA/vehicle_signal_specification/releases/tag/v4.1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* [VSS 4.1](https://github.com/COVESA/vehicle_signal_specification/releases/tag/v4.1) | |
* [VSS 4.1](https://github.com/COVESA/vehicle_signal_specification/releases/tag/v4.1) (not fully tested) |
I think this is part of a broader question, like what do we consider as necessary to say that a VSS version is "fully supported" or "fully tested". For most repos we only use a single VSS-version as basis for demos/examples/tests. I actually do not know if latest version of for example Databroker still successfully can read all necessary info from a VSS 2.0 JSON file. Test wise we have for the latest releases only ran Databroker with the default VSS version (currently 4.0), and we likely for resource reasons do not want to test all versions for each release. We also This is kuksa-common, so maybe we should not even say something about what is supported/tested here, as this repo from one perspective should not know which repos that use the VSS versions and how they support them. So maybe just list them, and possibly list known limitations like what we have for VSS 3.1.0. But then we still have the question on how to list dependencies/requirements. Shall that then be stated by each component, so that for example kuksa-can-provider states which VSS version that is used by default and for testing, and also which databroker version that was used for testing. Or should we have some form of "global" Eclipse-Kuksa releases, were we state compatible version for individual components as well as VSS version recommended and/or used for testing and examples. Any thoughts @SebastianSchildt |
I tend to agree that this repo maybe should only collect the data. What might make sense, to point out which version is default in which databroker version (as that is sort of our core component) I.e. saying "VSS 4.0, (default in databroker 0.25, 0.3 , 32) <- Example I made that up! That would sort of implicitly make clear what combinations are tested |
Refactored text based on discussion |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM now
Adding copy of https://github.com/COVESA/vehicle_signal_specification/releases/download/v4.1/vss_rel_4.1.json
Note - Databroker still use local versions in https://github.com/eclipse/kuksa.val/tree/master/data/vss-core. I did a sanity check that Databroker could load this file, but actually integrating it into databroker and possibly making it default is a later step.