Drop GetSupportedVersions in favor of versioned proto package

[jdef]

As per the CSI discussion today regarding versioning:

• alternative to Versioned proto and golang package structure #195
  • we can add a Versioned service later if needed; doing it now isn't critical and it will be hard to remove later on if we decide we don't need it.
• fixes Consider adding vMAJOR version (e.g. csi.v1.) to either the API bindings or package names #193
  • allows v0.1 and v0.2 bindings to co-exist (we're aiming for v0.2 to be the last breaking API change set prior to v1.0)
  • the "v1" in the proto package name may or may not correspond to the major spec version; this PR does not decide that
  • removed GetSupportedVersions RPC as well as per-RPC request Version version = 1 field specs
• small Makefile changes to clean up generated code

[jdef]

If we decide to add a Versioned service later (and add back GetSupportedVersions) there will be ordering dependencies here.

[julian-hj]

I think that's ok...we would just need to add the version with a different position id. In other words, the following is totally valid:

message ControllerUnpublishVolumeRequest {
  Version version = 4;
  string volume_id = 1;
  ...
}

[jdef]

@jieyu @saad-ali @cpuguy83 @julian-hj PTAL

[jieyu]

This LGTM!

[julian-hj]

LGTM

[saad-ali]

the "v1" in the proto package name may or may not correspond to the major spec version; this PR does not decide that

Can we call it something else then, build1, iteration1, something to make it more obvious that this is not the something as the version of spec?

[cpuguy83]

v1-dev which gets bumped to v1 on release?
I'm not even really a big fan of that...
As long as it's clearly documented that this is for package namespacing and not signifying a formal release process, I think it's fine.

[saad-ali]

I guess what will get confusing is, if I want to support v1.2 and v1.3 how do I know which of these internal versions correspond to that external version. If we just align our external release versions with the internal version, that would be trivial.

[jieyu]

If you guys are concerned with using v1 at this moment, i'd suggest use v0 for this release, and try to jump to v1 and 1.0 in the next release.

[cpuguy83]

The package namespacing is very much tied to the release, but there is no need to bump the package namespacing to support new features, which is why it's tied to vMAJOR.

[saad-ali]

If you guys are concerned with using v1 at this moment, i'd suggest use v0 for this release, and try to jump to v1 and 1.0 in the next release.

I like this idea. Tying the package name to the Major release makes sense. We can call this v0 and push to get to v1 sooner.

[jieyu]

@cpuguy83 @julian-hj are you guys ok with s/v1/v0/ in this PR. If yes, i'll prepare a commit since @jdef is out today

[cpuguy83]

I think that works.

[julian-hj]

Yeah, sure. It has the down-side that we will be striking a new api version when we go 1.0 whether we need to or not, but I think it’s better to do that than live with the off-by-one discrepancy forever. From: Jie Yu <[email protected]<mailto:[email protected]>> Reply-To: container-storage-interface/spec <[email protected]<mailto:[email protected]>> Date: Friday, February 23, 2018 at 12:36 PM To: container-storage-interface/spec <[email protected]<mailto:[email protected]>> Cc: Corporate User <[email protected]<mailto:[email protected]>>, Mention <[email protected]<mailto:[email protected]>> Subject: Re: [container-storage-interface/spec] Drop GetSupportedVersions in favor of versioned proto package (#202) @cpuguy83<https://github.com/cpuguy83> @julian-hj<https://github.com/julian-hj> are you guys ok with s/v1/v0/ in this PR. If yes, i'll prepare a commit since @jdef<https://github.com/jdef> is out today — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#202 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AIF0_JiG4f4xBCNhgFBorZHn2pnPO6oCks5tXyFQgaJpZM4SQHcJ>.

[jieyu]

Resolved by #204