Adding 2025-01-01 Stable version - exact copy of 2024-11-01-preview

[jeremyfrosti]

ARM (Control Plane) API Specification Update Pull Request

[!TIP] Overwhelmed by all this guidance? See the Getting help section at the bottom of this PR description.

PR review workflow diagram

Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

Purpose of this PR

What's the purpose of this PR? Check the specific option that applies. This is mandatory!

• [ ] New resource provider.
• [x] New API version for an existing resource provider. (If API spec is not defined in TypeSpec, the PR should have been created in adherence to OpenAPI specs PR creation guidance).
• [ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
• [ ] Update existing version to fix OpenAPI spec quality issues in S360.
• [ ] Convert existing OpenAPI spec to TypeSpec spec (do not combine this with implementing changes for a new API version).
• [ ] Other, please clarify:
  • edit this with your clarification

Due diligence checklist

To merge this PR, you must go through the following checklist and confirm you understood and followed the instructions by checking all the boxes:

• [x] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
• [x] I have reviewed following Resource Provider guidelines, including ARM resource provider contract and REST guidelines (estimated time: 4 hours).
  I understand this is required before I can proceed to the diagram Step 2, "ARM API changes review", for this PR.
• [ ] A release plan has been created. If not, please create one as it will help guide you through the REST API and SDK creation process.

Additional information

Viewing API changes

For convenient view of the API changes made by this PR, refer to the URLs provided in the table in the Generated ApiView comment added to this PR. You can use ApiView to show API versions diff.

Suppressing failures

If one or multiple validation error/warning suppression(s) is detected in your PR, please follow the suppressions guide to get approval.

Getting help

• First, please carefully read through this PR description, from top to bottom. Please fill out the Purpose of this PR and Due diligence checklist.
• If you don't have permissions to remove or add labels to the PR, request write access per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories
• To understand what you must do next to merge this PR, see the Next Steps to Merge comment. It will appear within few minutes of submitting this PR and will continue to be up-to-date with current PR state.
• For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure and https://aka.ms/ci-fix.
• For help with ARM review (PR workflow diagram Step 2), see https://aka.ms/azsdk/pr-arm-review.
• If the PR CI checks appear to be stuck in queued state, please add a comment with contents /azp run. This should result in a new comment denoting a PR validation pipeline has started and the checks should be updated after few minutes.
• If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.
• For guidance on SDK breaking change review, refer to https://aka.ms/ci-fix.

[github-actions[bot]]

Next Steps to Merge

Next steps that must be taken to merge this PR:

• ❌ This PR is in purview of the ARM review (label: ARMReview). This PR must get ARMSignedOff label from an ARM reviewer.
  This PR has ARMChangesRequested label. Please address or respond to feedback from the ARM API reviewer.
  When you are ready to continue the ARM API review, please remove the ARMChangesRequested label.
  Automation should then add WaitForARMFeedback label.
  ❗If you don't have permissions to remove the label, request write access per aka.ms/azsdk/access#request-access-to-rest-api-or-sdk-repositories.
  For details of the ARM review, see aka.ms/azsdk/pr-arm-review
  
• ❌ The required check named Swagger Avocado has failed. Refer to the check in the PR's 'Checks' tab for details on how to fix it and consult the aka.ms/ci-fix guide

Comment generated by summarize-checks workflow run.

[github-actions[bot]]

API Change Check

APIView identified API level changes in this PR and created the following API reviews

Language	API Review for Package
Java	com.azure.resourcemanager:azure-resourcemanager-sql-generated
C#	Azure.ResourceManager.Sql
Python	azure-mgmt-sql
Go	sdk/resourcemanager/sql/armsql
JavaScript	@azure/arm-sql

[razvanbadea-msft]

required checks fails probably because readme was not modified to include the new version

[jeremyfrosti]

/azp run

[azure-pipelines[bot]]

Commenter does not have sufficient privileges for PR 38470 in repo Azure/azure-rest-api-specs

[jeremyfrosti]

I've added the new tag for the stable version to the readme, and I updated the default tag to be the new tag (as we were asked to use a uniform version for our tag by ARM). This is presenting an Avocado error though as that tag does not contain any of the 2014 APIs that are being deprecated. We don't want those APIs in the default tag either, as we want all future SDKs to not include them.

[sandipsh]

please ensure all validation errors are appropriately handled and looks green before requesting ARM feedback. there are lots of lintdiff and avocado errors for the new api version.

[jeremyfrosti]

On the errors:

What this PR is doing is adding our Microsoft.SQL 2025-01-01 stable version to the rest API specs. This version is identical to our already released 2024-11-01-preview (our system on the SQL side treats them exactly the same). We used to just drop the "-preview" for our stable versions but were asked to switch to using a new version number to follow ARM's versioning guidelines.

The Avocado errors the PR is hitting are due to the fact that I changed the default tag to point to the new stable tag. This was done as we were told that we have to switch to using a uniform version tag, but this causes Avocado errors because we have APIs that only exist in our old legacy APIs that have been on the deprecation path for 3+ years now. Are we allowed to proceed with this change or is there some other process to follow? I could theoretically change the default tag back to the composite tags we usually use, but this would still have to be addressed down the line anyway.

On the LintDiff errors, these are all already part of the 2024-11-01-preview version, its not something that we can change for releasing a stable versions, and there are more lintdiff errors than we could handle at any one time (we have been working every release on reducing these, but its a massive task).

This exact version has already been approved by ARM before in the last preview version, including the lintdiff errors that were present: https://github.com/Azure/azure-rest-api-specs/pull/35794

[psah434]

Model validation is also failing. Is there an ETA on when the lint diff errors will be fixed?

[jeremyfrosti]

@psah434 I have fixed the model validation issues. On the LintDiff exceptions, our plan is to not allow any new ones in the future and slowly work through the existing ones as we update those resources, but we don't have an exact ETA given how large and spread out the work is.

[ramoka178]

@psah434 I have fixed the model validation issues. On the LintDiff exceptions, our plan is to not allow any new ones in the future and slowly work through the existing ones as we update those resources, but we don't have an exact ETA given how large and spread out the work is.

@jeremyfrosti Can you add suppressions in the readme file only to those that are flagged now, with the file name and the path/where clause. Else, this process of going back to previously approved PRs will always happen until you fix them.

[qiaozha]

@jeremyfrosti you can add the LintDiff suppressions by referring to this document https://github.com/Azure/azure-rest-api-specs/wiki/Swagger-LintDiff#adding-scoped-suppressions