-
Notifications
You must be signed in to change notification settings - Fork 68
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
Add data plane fields w/ renamed Worker Versioning concepts #514
base: master
Are you sure you want to change the base?
Conversation
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.
General concerns about deprecating so many things a few weeks after merging it. I just want to make sure we understand the consequences of ever removing API.
But only change requested is to add deprecated options.
@@ -251,11 +251,20 @@ message WorkflowTaskCompletedEventAttributes { | |||
// The deployment that completed this task. May or may not be set for unversioned workers, | |||
// depending on whether a value is sent by the SDK. This value updates workflow execution's | |||
// `versioning_info.deployment`. | |||
// Deprecated. Replaced with `deployment_name` and `deployment_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.
I admit I am a bit concerned about the idea of removing this later. This was just merged a couple months ago and now it's being deprecated.
It is very important we try our best not to make backwards incompatible changes to released API, even if we think it is unused. Customers build proxies and have code generators and in general have stability expectations on our API. We have broken users in the past by making incompatible changes to API (again, even if unused by our SDKs as our SDKs are not the only ones that expect API stability). This strive for API stability includes pre-release/public-preview API because unlike SDKs, we cannot make assumptions about downstream consumption.
Also, if this field is ever set, removing this will make history JSON incompatible and we strive to make history always backwards (and forwards) compatible even pre-release/public-preview histories.
@@ -251,11 +251,20 @@ message WorkflowTaskCompletedEventAttributes { | |||
// The deployment that completed this task. May or may not be set for unversioned workers, | |||
// depending on whether a value is sent by the SDK. This value updates workflow execution's | |||
// `versioning_info.deployment`. | |||
// Deprecated. Replaced with `deployment_name` and `deployment_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.
Can you add [deprecated = true];
to all deprecated fields?
READ BEFORE MERGING: All PRs require approval by both Server AND SDK teams before merging! This is why the number of required approvals is "2" and not "1"--two reviewers from the same team is NOT sufficient. If your PR is not approved by someone in BOTH teams, it may be summarily reverted.
What changed?
The following concepts in Worker Versioning V3 is being renamed. This PR adds the data plane fields with new names so SDK can populate them like the old ones.
DeploymentSeries
->WorkerDeployment
Deployment
->WorkerDeploymentVersion
Also
WorkerVersionCapabilities
and itsuse_versioning
boolean are replaced withWorkerDeploymentOptions
andWorkflowVersioningMode
enum to be more compatible with V3 changes and also extensible in the future.RespondActivityTask*Request
used to senddeployment
but that is now deprecated. Since Server does not have any anticipated use for these values, I did not add a replacement for them at the moment.Why?
See ^^
Breaking changes
Not breaking, some things are deprecated that will be cleaned up at a later time with other old Versioning stuff.
Server PR
Server PR will follow soon. But these changes should not break server compile because methods are not touched.