Skip to content
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

proposal: modify sender info version element #174

Open
laroque opened this issue Jan 13, 2018 · 1 comment
Open

proposal: modify sender info version element #174

laroque opened this issue Jan 13, 2018 · 1 comment

Comments

@laroque
Copy link
Member

laroque commented Jan 13, 2018

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.

@wcpettus
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants