Consider adding vMAJOR version (e.g. csi.v1.) to either the API bindings or package names

[saad-ali]

Based on @akutz's proposal in: #171 (comment)

While this is not a 0.2 blocker, it should be considered before 1.0.

[akutz]

I propose it for v0.2, because every time this is punted is a time Go related CSI code cannot easily to the point of not possible be backwards compatible with earlier versions. This especially sucks for something like csc where it should absolutely support multiple API versions.

[saad-ali]

I would like to propose cutting a 0.2 release by end of next week so we can pick up 0.2 for Kubernetes. Can we get this in time for that? If so, I have no problem with it. @jdef @jieyu @julian-hj @cpuguy83 for their thoughts.

[akutz]

Hi @saad-ali,

You're a eager beaver, aren't ya? Man, I'm just getting SPs up to snuff with 0.1.0 and here you go with 0.2.0 :)

[akutz]

Hi @saad-ali,

I can get a PR submitted for people to look at. At least that will spur some discussion.

[saad-ali]

Ha, yes, I'd like Kubernetes to ship with 0.2 since there are so many breaking changes between 0.1 and 0.2.

[cpuguy83]

Do we need to version each pre-release package? My inclination would be to just keep it at v1 and v1 won't be stable until we actually hit the v1 release, or alternatively v1-dev and bump to v1 when the protos are finalized.

I doubt CO's will suport multiple pre-release versions at the same time.
I suppose it can make it easier for SP's where different CO's may be supporting a different version, though.

[jdef]

I'd rather not see versioned pre-release packages. AFAIK the goal was to provide a mechanism for dealing with breaking API changes post-v1. Pre-v1 we're all working under the assumption that there will be periodic API breakage (though we will try very hard to avoid breakage after v0.2)

…

On Fri, Feb 16, 2018 at 10:44 AM, Brian Goff ***@***.***> wrote: Do we need to version each pre-release package? My inclination would be to just keep it at v1 and v1 won't be stable until we actually hit the v1 release, or alternatively v1-dev and bump to v1 when the protos are finalized. I doubt CO's will suport multiple pre-release versions at the same time. I suppose it can make it easier for SP's where different CO's may be supporting a different version, though. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#193 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACPVLJSNKE67rOpW_lanryTIlbj9DCNLks5tVaJXgaJpZM4SHwkX> .

[akutz]

I prefer we version each pre release because some of us do have to keep up with dozens of instances of this stuff. A compromise would be to treat the prerelease versions like release versions so 0.1 is v1, and just understand that upon release everything starts over.

[jdef]

Strongly disagree that v0.1 should be modeled as v1

…

On Fri, Feb 16, 2018 at 11:11 AM, Schley Andrew Kutz < ***@***.***> wrote: I prefer we version each pre release because some of us do have to keep up with dozens of instances of this stuff. A compromise would be to treat the prerelease versions like release versions so 0.1 is v1, and just understand that upon release everything starts over. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#193 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACPVLEsmLmQSZdeLp-3Yyeep9P9W9G-3ks5tVaiXgaJpZM4SHwkX> .

[akutz]

Hi @jdef,

Which is why in my PR I allowed for a leading zero if the MAJOR component was zero. For example:

csi.vMAJOR(MINOR)? where MINOR is added if MAJOR is 0. For example:

Version	Package Name
v0.2.0	csi.v02
v2.1.0	csi.v2

However, please do what you feel is correct. Thank you for including me in these discussions. I've always appreciated it.

[jdef]

If the intent is to provide a packaging and versioning mechanism that works for breaking spec changes PRIOR to v1 then we should include MINOR somehow. I'm under the impression that such granularity is out of scope for now. That said, I can see the potential usefulness of it as we continue to iterate prior to releasing v1.

For example, considering MINOR prior to v1 would simplify life for SP's who want to ship a single plugin package that works across COs that implement various spec revisions prior to v1. That said, it may be a moot point if the nature of the spec changes are drastic: an SP might be better off shipping separate artifacts in such cases: either way their software would be attempting accommodate multiple runtime environments.

Supporting MINOR prior to v1 would also make life easier for CSI middleware projects. One concern that I have is that by supporting MINOR prior to v1 we'll end up with a mini explosion of spec variants as we iterate across breaking sub-releases -- and that they'd all end up on HEAD in some form or another (considering the approach taken by #195).

Thoughts from others? @jieyu @saad-ali @cpuguy83 @julian-hj

[saad-ali]

One concern that I have is that by supporting MINOR prior to v1 we'll end up with a mini explosion of spec variants as we iterate across breaking sub-releases -- and that they'd all end up on HEAD in some form or another (considering the approach taken by #195).

This is a valid concern. We could do MINOR versioning pre-1.0 and then switch to MAJOR versioning >=v1.0 (and remove all pre v1.0 from HEAD once 1.0 is cut)? That would allow us to develop and test this mechanism pre-1.0 as well.