You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently have sender_info.version which is of type string and described as "Sender package version"
In practice there are at least three different versions of interest (hopefully each in this list implies the one above):
wire protocol version
dripline implementation version
actual package version
Proposal
Change the type of this field to be a dictionary/map, where keys are the the versioned thing and values are version strings. The wire protocol version would always be required as would the version for the package itself. Any intermediate packages (like the dripline implementation) should be included if they exist.
This would allow us to use "standard" version strings in our packages and still include all of the useful information. It would also enable testing against the version of the wire protocol since the format of that string can be defined in the wire protocol itself.
The text was updated successfully, but these errors were encountered:
We were trying to roll out two coordinated updates to the wire protocol - this and the timestamp precision. And as a result we've gotten neither, although all supported dripline versions are ready for the timestamps.
The issue with this came from dripline-labview, which for awful labview reasons doesn't properly support json making this difficult to implement.
A couple of paths forward:
define a WP version for just the timestamps, implement that globally
a new WP version can be defined for this, which can be rolled out or not depending on sensitivity to actually checking the format of the sendor_info.version
bundle them together and roll out selectively, give labview a rude gesture, and claim it's not really fully supported anyway
keep waiting indefinitely until we can implement this in labview
We should just fix the timestamps, it's too easy, and it generates too many errors for operators.
We currently have
sender_info.version
which is of type string and described as "Sender package version"In practice there are at least three different versions of interest (hopefully each in this list implies the one above):
Proposal
Change the type of this field to be a dictionary/map, where keys are the the versioned thing and values are version strings. The wire protocol version would always be required as would the version for the package itself. Any intermediate packages (like the dripline implementation) should be included if they exist.
This would allow us to use "standard" version strings in our packages and still include all of the useful information. It would also enable testing against the version of the wire protocol since the format of that string can be defined in the wire protocol itself.
The text was updated successfully, but these errors were encountered: