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

Update uniform-versioning.md and glossary.md: minor fixups #29368

Merged
merged 2 commits into from
Jun 7, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion documentation/glossary.md
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ A data-plane service has a path of form:

> [!NOTE]
> Some existing services follow different directory structure layouts.
> All such layouts are legacy, deprecated, and not allowed going forward.
> All such layouts are legacy, deprecated, and strongly discouraged going forward.

For example, [`specification/containerservice/resource-manager/Microsoft.ContainerService/aks`]
is a folder for the `aks` service within the `Microsoft.ContainerService` ARM Resource Provider namespace.
Expand Down
7 changes: 5 additions & 2 deletions documentation/uniform-versioning.md
Original file line number Diff line number Diff line change
@@ -1,3 +1,6 @@
| Short Link: | [aka.ms/azsdk/uniform-versioning](https://aka.ms/azsdk/uniform-versioning) |
|--|--|

# Uniform versioning

> [!NOTE]
Expand All @@ -11,7 +14,7 @@ In brief, it means:
> If a new service API version is released, also a new documentation reference must be released to describe it.
> Similarly, a new version of given SDK package must be released to refer to the new service version.

Each `service` within a `service group` can version independently of each other.
Each `service` within a `service group` or `grouping directory` can version independently of each other.

## Uniform versioning rules

Expand Down Expand Up @@ -55,7 +58,7 @@ The **uniform versioning** has several implications and implementation decisions
### No API version mixing within a service

- Nowhere within a service, documentation for it, or SDK referencing it,
can multiple service API versions be mixed. as such:
can multiple service API versions be mixed. As such:
- `preview` API versions cannot be mixed with `stable` API versions.
- No HTTP API endpoint for given API version can have any kind of dependency on service endpoint from any other API version.
- The above apply to a stand-alone service as well as to a service that is a member of a `service group`.
Expand Down