API Stability and Versioning about azure-storage-blob-go

[landro]

Any updates on this @JeffreyRichter ?

[mohsha-msft]

Hey @landro ,

The reason I closed this issue is because we've been working on an updated version of Go blob SDK which will handle yours concerns and bring better design and user experience. We're using options bags (struct which can have more fields) which will stabilize the issue by handling new parameters which gets introduced with release. So we won't be fixing it here.

Stay tuned for more updates 😄

[tombuildsstuff]

cc-ing @joshgav (and @katbyte @ptyng from our end) - since we also raised this question IRL recently

[JeffreyRichter]

We have been improving the API in response to customer feedback. We also have an internal customer that is using this SDK very heavily and giving us feedback. Our hope is to put this library into General Availability be end of July or August.

Each SDK subdirectory is tied to a service API version like 2017-07-29. Within an SDK?service API version, we will make backward compatible improvements (like performance improvements or introduction of new APIs); we will NOT change existing API signatures.

However, when a new service API version comes out, we will introduce a new SDK for it. In this new SDK, we will try hard not to break API signatures but we do not guarantee it. A new service feature may require that we expose a new parameter so that customers can take advantage of it. Also, our SDK exposes a lot of AutoRest-generated data types. Future versions of AutoRest may change how they generate data types and these could cause breaking changes. While this is possible, it is unlikely and, within an SDK/service API version, we will use the same autorest version to ensure that generated data types do not change allowing us to maintain backwards compatibility within a single SDK/service API version. We do intend to formally document this versioning strategy as it applies to all of our new, rearchitected SDKs in all languages (Go, Async Java, Node, Python, .NET , etc.).

[zezha-msft]

Hi @landro, thanks for following up! We've exercised the SDK extensively through the AzCopy project and polished the rough edges. I expect the SDK to become GA soon after stress testing.

[michaelbironneau]

Thanks @zezha-msft - are you able to provide a timeline for the stress testing and GA release?

[zezha-msft]

@michaelbironneau I will have a better idea once the work is scheduled. I'll update this thread accordingly. Thanks!

[landro]

Are we talking weeks or months?

…

29. mai 2019 kl. 20:53 skrev Ze Qian Zhang ***@***.***>: @michaelbironneau I will have a better idea once the work is scheduled. I'll update this thread accordingly. Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[zezha-msft]

Hi @landro, 1-3 months would be my guess.

[zezha-msft]

@landro is this a concern for your use case?

[landro]

Indeed, @zezha-msft . We're implementing our entire infra using terraform, and right now soft delete isn't supported due to the api instability. See hashicorp/terraform-provider-azurerm#1070 for details.

[landro]

Why was this closed? @mohsha-msft