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

Bump tfplugin version to 5.1 #21650

Merged
merged 2 commits into from
Jun 7, 2019
Merged

Bump tfplugin version to 5.1 #21650

merged 2 commits into from
Jun 7, 2019

Conversation

jbardin
Copy link
Member

@jbardin jbardin commented Jun 7, 2019

#21611 added a new field to the ReadResource plugin method, which should also increment the minor version of the protocol.

This also adds the proto definitions to the ./docs/plugin-protocol/ directly, with filenames indication the full version for reference. The canonical file used to build the plugin package will still be located in the ./internal/tfplugin5/ directory, and be symlinked from ./docs/plugin-protocol/ to immediately reflect any minor format or textual changes. All previous versions of the file are considered frozen, and are only listed for reference.

With the addition of the private field to ReadResource, we need to bump
the proto version to 5.1.
@jbardin jbardin requested a review from a team June 7, 2019 19:31
@@ -0,0 +1 @@
../../internal/tfplugin5/tfplugin5.proto
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm my instinct was to invert this and make the other location be the symlink, to make it clearer that these files are considered immutable once "released".

I'm not super against this model, but I worry a bit that it will make it easier to forget to deal with the versioning concerns when updating it, and thus to create a confusing/ambiguous situation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, that works too! It won't help with the case where someone edits the file through the symlink in ./internal/tfplugin, but it makes the docs more of the "canonical source"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah... I was optimistically hoping that an editor would draw attention to the fact that's a symlink, but if not at least the eventual PR should show that there's an edit to a file called tfproto5.1 rather than the creation of a new file called tfproto5.2 and set of some ⏰ 😁

Add versioned tfplugin proto files to the docs directory, for easier
reference. The latest version starts as a symlink to the current
file used for generated the tfplugin package in ./internal/tfplugin5.

When changing the protocol version, the old file must be copied to
./docs/plugin-protocol/, and a new symlink created for the latest
version.
@jbardin jbardin force-pushed the jbardin/private-data-read branch from 3d3568d to fa1f9be Compare June 7, 2019 19:47
@jbardin jbardin merged commit 98997cc into master Jun 7, 2019
@jbardin jbardin deleted the jbardin/private-data-read branch June 7, 2019 20:32
@ghost
Copy link

ghost commented Jul 25, 2019

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Jul 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants