[SDK Generation] Allow setting SDK release type independently

[raych1]

There are scenarios where service team would like to release 'Beta' SDK while not specifying the 'api-version'.

[raych1]

there are situations where the service team wants to release a preview version before moving to stable. We also require that any new SDK package be previewed for one month before it becomes stable. For features that remain in preview for a long time, we may consider them stable as well.

@lirenhe for the above scenarios, I think users should be able to explicitly specify both api-version and sdk-release-type while releasing an SDK, right?

[raych1]

To support this, I propose adding a new option - none to the allowed values of the sdk-release-type parameter (see below screenshot). The behaviors would be:

• 'none' will be the default value
• When it is set to 'none', the pipeline decides the release type
• When users select beta or stable, that value is honored as the release type.

@praveenkuttappan @live1206 @XiaofeiCao @JiaqiZhang-Dev @msyyc @JialinHuang803
Can you check if this change will need further changes on downstream language automations and upstream pipeline callers?

@lirenhe
One important thing to call out, we currently enforce a validation check on the paring values between 'api-version' and 'sdk-release-type'. This check would fail if api-version is 'preview' but sdk-releast-type is 'stable'. I think we should keep this gating in place to avoid releasing a stable SDK from preview api specs.
CC: @lmazuel

[lirenhe]

One important thing to call out, we currently enforce a validation check on the paring values between 'api-version' and 'sdk-release-type'. This check would fail if api-version is 'preview' but sdk-releast-type is 'stable'. I think we should keep this gating in place to avoid releasing a stable SDK from preview api specs.

@raych1, yes, this is a special case that only happens for a small set of services. There could be some user experience design when creating release like above to confirm service team's intension/justification. Also, can you put some notification on the SDK PR created so SDK owners would be notified and review this case.

[msyyc]

Python is OK for the proposal.

[tadelesh]

I suppose the none type will not pass to language tools. If so, Go is OK.

[XiaofeiCao]

Looks good. No change needed for Java, if none means no sdk-release-type entry.

[raych1]

One important thing to call out, we currently enforce a validation check on the paring values between 'api-version' and 'sdk-release-type'. This check would fail if api-version is 'preview' but sdk-releast-type is 'stable'. I think we should keep this gating in place to avoid releasing a stable SDK from preview api specs.

@raych1, yes, this is a special case that only happens for a small set of services. There could be some user experience design when creating release like above to confirm service team's intension/justification. Also, can you put some notification on the SDK PR created so SDK owners would be notified and review this case.

@lirenhe
I don’t think we should relax this validation.
Even if this is a small set of services, making this behavior generally available creates system inconsistency and makes it harder to reason about releases.
From a technical perspective, ADO pipeline does not support interactive prompts or confirmations.
If there are real exceptions, we should handle them through an explicit controlled override — update api-version in the tspconfig.yaml.

[raych1]

@JiaqiZhang-Dev the change has been merged, and feel free to try.

[JiaqiZhang-Dev]

I tried the generation pipeline (https://dev.azure.com/azure-sdk/internal/_build/results?buildId=6368837&view=logs&j=83516c17-6666-5250-abde-63983ce72a49&t=00be4b52-4a63-5865-8e02-c61723ad0692), and it works now. Thank you very much!

[weidongxu-microsoft]

nit, should we use "auto" (instead of "none"), which should be more meaningful?

[raych1]

To keep it consistent with 'none' option in the api-version parameter. Both stands for letting emitter to determine the value.