-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Choose new default API versions #3448
Labels
Comments
thomas11
added
3.0
and removed
needs-triage
Needs attention from the triage team
labels
Jul 19, 2024
danielrbradley
added a commit
that referenced
this issue
Jan 10, 2025
Choosing default versions (#3448) is hard where there's multiple versions mixed into a single module. This is sometimes because we structure our modules around Azure's namespaces rather than the SDK folders. This PR allows us to selectively restructure problematic modules to match Azure's SDK structure (#690) and avoid mixing multiple versions into a single module. An example of the result of turning on the feature flag can be seen in 14db6d8 where we split out Dns, DnsResolver, FrontDoor, PrivateDns and TrafficManager from the Network module. Side note: when splitting the modules out, there's all previous versions generated for the new module. These will be reduced when we run the squeeze process. Manual report of all specification folders and the namespaces within them: [spec-dirs.csv](https://github.com/user-attachments/files/18345878/spec-dirs.csv) For the first Network module split, we've hard coded the new module names to use because the casing is not able to be derived from the folder name alone. In a follow-up PR we can investigate parsing the Readme.md files from the specifications to automatically infer the correct names and avoid hard-coding. Generate implementation approach: 1. Make naming overrides a functions instead of a map so we can make decisions based on the version switch and other information. 2. When overriding a module name, return the old name too and add aliases so it's easy for users to migrate.
First selection process is done in #3847. The next step is continuing testing and resolving any failing tests on the v3 branch. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Depends on #2661.
Can be done iteratively.
The text was updated successfully, but these errors were encountered: