search

devigned / profile-playground

2 stars 1 forks source link

[Bala] Single SDK client library version that would support multiple api-versions? #1

Open devigned opened 7 years ago

devigned commented 7 years ago

For C# SDK, Are we thinking shipping a single SDK version that would support multiple api-versions? It looks like though. We are just differentiating the namespace with the api-version.

devigned commented 7 years ago

In this prototype, the intention is to package multiple APIs into a single client library. For example, the compute library for version X.Y.Z would contain API version A, B, C for given resource types.

At this point, the differentiation is based on namespace.

balajikris commented 7 years ago

I like this idea, but I feel this makes semantic versioning the packages a bit fuzzy.

When should I increment the Major version of a package - a few situations below:

  1. When I introduce incompatible changes to an existing profile
  2. When I introduce a new profile
  3. Additionally, does incompatible changes to an existing api should never be made and we should simply make a new profile?
devigned commented 7 years ago
  1. We should never introduce incompatible changes to an existing profile -- they are long term support
  2. When a new profile is introduced, then it would be a minor version change. We have added new functionality only. It would be non-breaking.
  3. New Profiles should be defined by Azure, and created on a 6 month cadence.

The beauty of packaging these together, is that the only time we should make a breaking change is when the generator changes the code produced. Introduction of new functionality only introduces new APIs, so only minor increments. I think this actually clears up versioning a bit.