release-containerregistry-mgmt-fix-issue-7763 #9111
Conversation
|
@qiaozha Can you share which swagger file did you use to generate this? There seems to be a lot of new apis introduced, but when I look at the history of the stable api swagger spec, I don't see any significant changes since last June when the sdk was last generated. |
Actually I am using the latest https://github.com/Azure/azure-rest-api-specs/commits/master/specification/containerregistry/resource-manager/readme.md as input which contains the default tag change. Now it's package-2019-12-preview |
|
@qiaozha Was there a corresponding service team request to re-generate the sdks in all languages after Azure/azure-rest-api-specs#8646? Usually when we regenerate the management sdks as a reaction to a the dependency mismatch issues, there isnt much api change to deal with. I am a little nervous here as there are a lot of apis being added and some of them removed. Looks like other languages have been updating the client registry package more frequently. See history for python and .net. But the last time the JS SDK was updated was a year ago. Do you know why the JS SDK was lagging behind? |
|
Also, the .Net SDK that was generated last month using the latest swagger spec has the SDK version as "preview". Are you aware of when we decide to use a "preview" vs stable versioning strategy for the management sdks? cc @RodgeFu, @nickzhums |
|
@ramya-rao-a .NET SDK release is owned by the service team, so they decide on the versioning. It would really be a question for the specific service team |
@ramya-rao-a Okay, I am confirm it with the service team now. |
|
|
||
| const packageName = "@azure/arm-containerregistry"; | ||
| const packageVersion = "7.0.0"; | ||
| const packageVersion = "8.0.0"; |
There was a problem hiding this comment.
because the api version is "package-2019-12-preview", the SDK should be preview too, isn't it?
There was a problem hiding this comment.
Currently there's no preview tag in JS SDK
There was a problem hiding this comment.
There is nothing stopping us from using previews in the package version. The main question would be as to what tag would the release get. In the data plane libraries, when we want to release preview packages for a package that is already gone GA, we add the tag next to the release while retaining the tag latest for the GA release. This way, users by default will only get the stable version. People wanting to get the preview version should explicitly use that version.
There was a problem hiding this comment.
@ramya-rao-a Thanks for the information, @RodgeFu Should we also take data-plane strategy now? I think the current mgmt plane release pipeline doesn't support to release with tags?
There was a problem hiding this comment.
yes, i think we can do the same as data-plane. Let's add that support then. :)
There was a problem hiding this comment.
One thing to keep in mind is what the expectation from the service team is. If their expectation is that this preview version should be the default version everybody should get, then we cannot take the data plane strategy to add the next tag
There was a problem hiding this comment.
Yes. That's because we can't support multi-api like python SDK at this moment, and we have to choose a tag in their readme.md to release. so the preview tag is just like offical version.
There was a problem hiding this comment.
Ok, in that case, let's go with non preview version
fix issue #7763