search

driplineorg / dripline

Slow controls for medium scale physics experiments based on AMQP centralized messaging
http://driplineorg.github.io
2 stars 0 forks source link

proposal: modify sender info version element #4

Closed laroque closed 4 years ago

laroque commented 6 years ago

migrate project8/dripline issue 174

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.

laroque commented 5 years ago

I suggested today that this was maybe less critical because it isn't clear that we ever use the information we have now. Having thought about it a bit more, I think that whenever we make a major-version bumping change (#2) to the rest of the system we should include a move to this structure. If it is more work than we're willing to deal with for now, we can skip dealing with the support for derived packages to add their version information and just nest the existing information. That will cover the compatibility-breaking change and we can add the rest as a minor-version bumping enhancement later (or maybe it is easy with a singleton or some such).

laroque commented 5 years ago

We've accepted the spirit of this proposal. The values of each version will be a structure which includes a version string, probably also a commit hash and a package reference (keys of the version structure would be the package name, like "dripline-cpp" whereas the reference would be "driplineorg/dripline-cpp", to provide a way to clarify in the case of a fork... though the programmatic implementation of that is of course to be dealt with)

nsoblath commented 4 years ago

Has been implemented in dripline-cpp