autorest.typescript icon indicating copy to clipboard operation
autorest.typescript copied to clipboard

[RLC] Support Versioning

Open joheredi opened this issue 1 year ago • 4 comments

This Pr introduces initial support for versioning in RLC and puts it under the experimental feature flag.

For now this generates N times where N is the number of versions in the spec, each RLC is put under a folder named after the version

src/
   v1/
   v2/
index.ts

It also generates a root level index.ts to export each version as a sub module, so customers can import it as:


import { v1 } from "@azure-rest/my-lib"

const client = v1.getClient();

Followup PRs will include exporting a "default" version in the root, and a later PR expand this support to Modular

joheredi avatar Feb 17 '24 18:02 joheredi

Should we have a small review for versioning in rlc support, I remember our previous discussion about this is we should have each RLC package per each endpoint each version ? Personally, I am in favor of this approach to support versioning in RLC. :)

qiaozha avatar Feb 18 '24 01:02 qiaozha

Should we have a small review for versioning in rlc support, I remember our previous discussion about this is we should have each RLC package per each endpoint each version ? Personally, I am in favor of this approach to support versioning in RLC. :)

At some point before taking it out of the experimental flag, we definitely need a review. I was working closely with @bterlson on this and he is on board with the overall approach. I think we can go ahead implementing it and have a GA review once the implementation is completed for both RLC and Modular

joheredi avatar Feb 18 '24 04:02 joheredi

Also, I remember that Mike has pointed out, in the case of deprecating, service team still need to maintain the old version for about two years until it's retired, but client side like SDKs should stop releasing the SDK to include the apis that are deprecated. And typespec is representing both service side and client side if I understand correctly ?

qiaozha avatar Feb 18 '24 08:02 qiaozha

Also, I remember that Mike has pointed out, in the case of deprecating, service team still need to maintain the old version for about two years until it's retired, but client side like SDKs should stop releasing the SDK to include the apis that are deprecated. And typespec is representing both service side and client side if I understand correctly ?

I think at that point the service team would remove the deprecated version from the spec. That doesn't mean they stop servicing, they can still maintain the service version, just that any new code gen won't include the deprecated version(s). @bterlson to confirm.

joheredi avatar Feb 20 '24 01:02 joheredi

Hi @joheredi. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

Hi @joheredi. Thank you for your contribution. Since there hasn't been recent engagement, we're going to close this out. Feel free to respond with a comment containing "/reopen" if you'd like to continue working on these changes. Please be sure to use the command to reopen or remove the "no-recent-activity" label; otherwise, this is likely to be closed again with the next cleanup pass.