Skip to content
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

Open
thomas11 opened this issue Jul 19, 2024 · 1 comment · May be fixed by #3846
Open

Choose new default API versions #3448

thomas11 opened this issue Jul 19, 2024 · 1 comment · May be fixed by #3846
Assignees
Labels
3.0 kind/enhancement Improvements or new features

Comments

@thomas11
Copy link
Contributor

thomas11 commented Jul 19, 2024

Depends on #2661.

Can be done iteratively.

@thomas11 thomas11 converted this from a draft issue Jul 19, 2024
@pulumi-bot pulumi-bot added the needs-triage Needs attention from the triage team label Jul 19, 2024
@thomas11 thomas11 added 3.0 and removed needs-triage Needs attention from the triage team labels Jul 19, 2024
@mikhailshilkov mikhailshilkov added the kind/enhancement Improvements or new features label Jul 22, 2024
@mjeffryes mjeffryes added this to the 0.114 milestone Dec 3, 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.
This was referenced Jan 10, 2025
@danielrbradley
Copy link
Member

danielrbradley commented Jan 15, 2025

First selection process is done in #3847. The next step is continuing testing and resolving any failing tests on the v3 branch.

@mjeffryes mjeffryes modified the milestones: 0.114, 0.115 Jan 17, 2025
@mikhailshilkov mikhailshilkov removed this from the 0.115 milestone Jan 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.0 kind/enhancement Improvements or new features
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

6 participants