-
Notifications
You must be signed in to change notification settings - Fork 19
incorporated version in the Transmitter Configuration Metadata. Added… #123
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
Conversation
… the Versioning Proposal previously adopted by the WG as a tracked document
| 3. **Breaking Change**: The new version makes changes to the Latest Spec. Implementations need to be updated in order to be able to work with any implementation of this new version. | ||
|
|
||
| **Note** that the change is always compared against the Latest Spec, and not against previous working group drafts. | ||
| Versioning Proposal |
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.
Is this a heading? It needs markdown I think
|
|
||
| version | ||
|
|
||
| > OPTIONAL. A string representation of a decimal number including a decimal point and at least one number after the decimal point even if it is 0. This indicates the version of the specification the Transmitter adheres to. The version number is determined according to the Versioning ({{VERSIONING}}) specification. The version number of the current specification is "1.0". If the `version` field is missing in the Transmitter Configuration Metadata, then the version number is assumed to be "0.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.
- A transmitter may want to support both 0.1 and 1.0 versions.
- A receiver may want to consume APIs with specific version
Should the receiver indicate which version it can consume by the headers to the API calls?
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.
I think since the API is incompatible between 0.1 and 1.0, a Transmitter wishing to support both will have to provide two different endpoints, so each metadata can still refer to just one version.
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.
Should the version be part of the API endpoints? Should the API version part of the API URLs or headers? Without that transmitter would not be able to distinguish receivers.
I feel, there also should be a notion of which version of the spec the receiver supports to allow version negotiation.
|
Based on WG discussions and discussions with Mike Jones and Mark Haine, this PR is no longer required. |
… the Versioning Proposal previously adopted by the WG as a tracked document