Choice-VR optional #180
Choice-VR optional #180
Conversation
|
@theresalech The proposal is ready for review. |
proposals/NNNN-choice-vr-optional.md
Outdated
| - `resultCode` = `INVALID_DATA`, | ||
| - `info` = "Some choices don't contain VR commands." | ||
|
|
||
| A planned proposal for a choice set manager could benefit from this proposal by automatically omit `vrCommands` if `vrCapabilities` is empty (assuming it already exist and the app is using it...). |
There was a problem hiding this comment.
Please change "omit" to "omitting" and "exist" to "exists" in this sentence.
proposals/NNNN-choice-vr-optional.md
Outdated
|
|
||
| ## Proposed solution | ||
|
|
||
| This proposal is to make the paramter `vrCommands` optional. This would allow apps to avoid unnecessary vr commands if they want to perform an interaction in manual mode. On the other hand it saves a lot of time of grammar computing on the head unit side. |
There was a problem hiding this comment.
"paramter" -> "parameter"
| ## Impact on existing code | ||
|
|
||
| - This proposal is a major change on Core and HMI. | ||
| - It's a very minor change for the SDKs. Properties have to become optional/nullable. |
There was a problem hiding this comment.
What do you mean by "major change", as in a major API change that requires a new major version of Core?
On the "SDKs", by which I assume you mean the mobile libraries, "a very minor change" is not precise. This is a minor version change (e.g. 1.X.0, where X changes).
There was a problem hiding this comment.
I'm not talking about version changes. I was comparing the effort to implement this proposal but I can remove those lines as they are pretty much pointless.
There was a problem hiding this comment.
Can you clarify both the implementation effort and semantic version changes? For example, "This proposal will require a large effort to implement for Core and HMI, and will be a minor version change because..."
There was a problem hiding this comment.
@theresalech Although this proposal is not of a big deal I don't think I can decide about the version change and I don't believe it should be mentioned within the proposal (unless it's required to be careful when to add the feature).
I cannot estimate the effort on Core and HMI but I'm pretty sure it's more of an effort than on the library side.
There was a problem hiding this comment.
Version changes are deterministic according to https://semver.org, so you absolutely should specify what the version change is.
There was a problem hiding this comment.
Since when is it required to specify this?
There was a problem hiding this comment.
It isn't required, but it's the first thing anyone will want to know. "What is the impact of the change on developers?" Which is answered by answering, "What is the type of version change?" So it isn't required, but it's certainly helpful.
|
@theresalech please mark this PR as ready as the requested change is not required. |
|
@kshala-ford even though it isn't "required" I would recommend you provide it. |
ghost
deleted the
ghost
mentioned this pull request
This proposal is about changing Choice.vrCommands to be not mandatory.