Going forward, a small number of specs may use the "v1/v2/..." versioning scheme (in parallel with date-based versions). To support these:

1. Split versions into two groups. Date-based (YYYY-MM-DD) and semver-based (N.N, vN, vN.N, etc). If neither match, error?
2. Sort date-based and sem-ver based (separately)
3. Rule NOT_LATEST_API_VERSION_IN_DEFAULT_TAG should allow either the latest date-based or semver-based version.
4. If needed, vN should be compatible with the latest date-based version (at the time).

We should also add this to spec-model, instead of special-casing in Avocado.

This should allow us to support both version schemes without any tooling breaking changes.

Example specs

New

• https://github.com/Azure/azure-rest-api-specs/tree/main/specification/ai/data-plane/Azure.AI.Agents/stable
• v1 allows non-breaking changes without a new API version
• 2025-05-01 follows normal date-based breaking changes rules

Legacy

• https://github.com/Azure/azure-rest-api-specs/tree/main/specification/keyvault/data-plane/Microsoft.KeyVault/stable
• 7.0 - 7.6 are legacy, no more versions of this format should be added
• 2025-07-01 supercedes all number-based versions, and all future versions should use dates