Add version-progression linter rule (Rule 7)

[Copilot]

• Merge latest main into the working branch (resolved linter doc conflict by accepting incoming relative-link format)
• Rebuild @azure-tools/typespec-azure-resource-manager and rerun pnpm regen-docs
• version-progression rule (file, exports, ruleset entry, docs, chronus changelog) — arm- prefix dropped per review
• Removed isInternalTypeSpec early-return per review
• Reference the linter rule from docs/howtos/Versioning/01-about-versioning.md
• Run pnpm format (no changes needed) and verify lint
• Verify PR diff vs main contains only the 8 expected files for this rule

[markcowl]

@copilot There is one fundamental change here. No api-version is allowed to use the same date as any other api-version. That is, there can be no preview version and stable version that have the same date (i.e. 2026-04-28 and 2026-04-28-preview are *not allowed) The dates in api-versions must all be different, and they must be monotonically increasing from the top to the bottom of the Versions enum for a namespace.

Please add tests that ensure a violation in this case, please look over tests to see if they need to be updated, please make sure all tests pass, and that you are up to date with the main branch

[Copilot]

@copilot There is one fundamental change here. No api-version is allowed to use the same date as any other api-version. That is, there can be no preview version and stable version that have the same...

Updated in 89d52fe. The rule now enforces that every api-version uses a unique YYYY-MM-DD date — preview and stable versions sharing a date (e.g. 2026-04-28 + 2026-04-28-preview) emits a duplicateDate diagnostic. Dates must still be strictly monotonically increasing top-to-bottom.

Test updates:

• Replaced the old "preview before stable on same date is valid" test with one that asserts a duplicateDate diagnostic for that case.
• Added an explicit test using 2026-04-28 + 2026-04-28-preview (the exact example from your comment).
• Added a test for two preview versions sharing a date.
• Existing "out of chronological order" test still asserts notMonotonic.

Branch is up to date with main. Full suite passes: 298/298 RM tests, 3/3 rulesets tests, eslint clean, pnpm format clean.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@azure-tools/typespec-azure-resource-manager@4347

npm i https://pkg.pr.new/@azure-tools/typespec-azure-rulesets@4347

commit: c0f8f05

[markcowl]

@copilot It looks like there are changes to website docs in the ci build. Please ensure you have rebuilt docs from the typespec-azure-resource-manager directory, and ensure that all files are formatted correctly. Also, please pull the latest from main and ensure that only changes associated with this PR are in the PR diff

[Copilot]

@copilot It looks like there are changes to website docs in the ci build. Please ensure you have rebuilt docs from the typespec-azure-resource-manager directory, and ensure that all files are format...

Addressed in fe563a0. Ran pnpm regen-docs from packages/typespec-azure-resource-manager, which added the arm-version-progression row to the auto-generated linter listings in packages/typespec-azure-resource-manager/README.md and website/src/content/docs/docs/libraries/azure-resource-manager/reference/linter.md. pnpm format reports no changes needed. Branch is up to date with main and the PR diff now contains only the 8 expected files for this rule.

[markcowl]

As always, make sure to pull the latest from main, make the suggested changes, alter tests to match, ensure that all tests pass, that all files are formatted correctly and that only the changes that are part of this PR are in the PR diff

[markcowl]

@copilot Please pull the latest from main, rebuild and rebuild the docs for typespec-azure-resource-manager, fix any merge conflicts, verify that all files are correctly formatted and only the changes associated with this PR are in the pr diff

[Copilot]

@copilot Please pull the latest from main, rebuild and rebuild the docs for typespec-azure-resource-manager, fix any merge conflicts, verify that all files are correctly formatted and only the change...

Done in 7a4ba03. Pulled latest from main (already merged in earlier commits 1176e13 and 797519c, no new conflicts), reran pnpm regen-docs from the typespec-azure-resource-manager directory, and ran pnpm format. Full test suite passes (299/299 RM, 3/3 rulesets) and lint is clean. The PR diff contains only the files associated with this rule.

[markcowl]

@copilot Please pull the latest from main, rebuild and rebuild the docs for typespec-azure-resource-manager, fix any merge conflicts, verify that all files are correctly formatted and only the changes associated with this PR are in the pr diff

[Copilot]

@copilot Please pull the latest from main, rebuild and rebuild the docs for typespec-azure-resource-manager, fix any merge conflicts, verify that all files are correctly formatted and only the changes...

Done in c552fca. Merged latest main into the branch (resolved one conflict in website/.../reference/linter.md by taking the incoming relative-link format), reran pnpm regen-docs from packages/typespec-azure-resource-manager, and ran pnpm format (no changes needed). Targeted test suite for the rule passes (8/8). PR diff vs main contains only the 8 expected files for this rule.

[markcowl]

/azp run typespec-azure - PR Tools

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

@copilot This rule is being applied in too many cases where the intent of the user is not clear. We should only try to determine if the finalResult matches the author's intended response when one of...

Just to make sure I'm working on the right thing — this PR adds the version-progression rule, which only validates that api-version dates in a Versions enum are unique and listed in strictly increasing chronological order. It doesn't inspect operation responses, finalResult, ActionAsync/ArmResourceActionAsync* templates, or 202+200/204 response pairings. The behavior you're describing sounds like a different LRO/final-state rule. Could you confirm whether this comment was intended for a different PR, or, if you'd like the change applied here, point me at the rule file you want updated? Happy to proceed once I know which rule to modify.