separate library version from feature version #316
Conversation
internal/internal_utils.go
Outdated
| // languageHeaderName refers to the name of the | ||
| // tchannel / http header that contains the client | ||
| // language | ||
| languageHeaderName = "cadence-client-language" |
There was a problem hiding this comment.
I would rename it to cadence-client-name
and value be something like uber-go, uber-java, as someone else can create mylibrary-java, etc.
There was a problem hiding this comment.
May be even call it user-agent to match HTTP?
There was a problem hiding this comment.
changed to be "cadence-client-name" : "uber-go"
internal/version.go
Outdated
| // feature set of this cadence client library support. | ||
| // This can be used for client capibility check, for | ||
| // backward compatibility | ||
| const FeatureVersion = "1" |
There was a problem hiding this comment.
I think it should also be semantic version with MAJOR.MINOR version of the server it was tested against. The server itself would have MAJOR.MINOR.PATCH version, where PATCH would be for any changes that are not API changing.
There was a problem hiding this comment.
so what about this:
internally, we keep 3 version number on the client side (major, minor, patch), and when exposing to customer who relying on the version number, we just exposed_version = sprintf("v%s.%s.%s"), i.e. "v1.2.3"
when piggy the version back to server, we send back 3 version separately, like:
"cadence-client-major-ver": "1"
"cadence-client-minor-ver": "2"
"cadence-client-patch-ver": "3"
to avoid parsing.
There was a problem hiding this comment.
I'm confused what version are you talking about?
For feature version only two numbers are necessary, and parsing is trivial.
For client version there is no need for parsing yet.
internal/version.go
Outdated
| // by the cadence team as part of a major feature or | ||
| // behavior change | ||
|
|
||
| // LibraryVersion is a semver string that represents | ||
| // the version of this cadence client library | ||
| const LibraryVersion = "v0.5.0" |
There was a problem hiding this comment.
This version should represent API changes visibile to Cadence client side library consumers. I.e. developers that are writing workflows. So every time we change API that can affect them we have to change this number. And we can even add code to validate that workflow definition matches it in the future.
separate the library version from feature version, also include the client lang in the rpc call to service.