Skip to content

Add examples to roll-forward table #46238

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+19 −6
Open

Add examples to roll-forward table #46238

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
25 changes: 19 additions & 6 deletions includes/roll-forward-table.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,16 +1,29 @@
---
author: adegeo
ms.author: adegeo
ms.date: 07/08/2021
ms.date: 05/16/2025
ms.topic: include
recommendations: false
---

| Value | Description |
|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `Minor` | **Default** if not specified.<br>Roll-forward to the lowest higher minor version, if requested minor version is missing. If the requested minor version is present, then the `LatestPatch` policy is used. |
| `Major` | Roll-forward to the next available higher major version, and lowest minor version, if requested major version is missing. If the requested major version is present, then the `Minor` policy is used. |
| `LatestPatch` | Roll-forward to the highest patch version. This value disables minor version roll-forward. |
| `LatestMinor` | Roll-forward to highest minor version, even if requested minor version is present. |
| `LatestMajor` | Roll-forward to highest major and highest minor version, even if requested major is present. |
| `Minor` | **Default** if not specified.<br>Roll-forward to the lowest higher minor version (and highest available patch version within that minor version), if requested minor version is missing. If the requested minor version is present, then the `LatestPatch` policy is used. |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even though I wrote this years ago, it took me quite a while to decipher what "lowest higher minor version" actually is. I wonder if using something like next available minor version or first higher available minor is clearer? I'm not sure though.. thoughts?

| `Major` | Roll-forward to the next available higher major version (at its lowest available minor version, and highest available patch version within that minor version), if requested major version is missing. If the requested major version is present, then the `Minor` policy is used. |
| `LatestPatch` | Roll-forward to the highest patch version available for the requested major and minor versions. This value disables minor version roll-forward. |
| `LatestMinor` | Roll-forward to the highest minor version available for the requested major version (and highest available patch version within that minor version), even if requested minor version is present. |
| `LatestMajor` | Roll-forward to highest available major version (and highest available minor and patch version within that major version), even if requested major is present. |
| `Disable` | Don't roll-forward, only bind to the specified version. This policy isn't recommended for general use since it disables the ability to roll-forward to the latest patches. This value is only recommended for testing. |

For example, suppose an application requests version `8.0.0`, while the locally available versions are `8.2.0`, `8.2.3`, `8.4.5`, `9.0.0`, `9.0.6`, `9.7.8`.
Then the resolved version is as follows in each case:

| Value | Resolved version | Resolved version if `8.0.1` were also available |
|---------------|------------------|-------------------------------------------------|
| `Minor` | `8.2.3` | `8.0.1` |
| `Major` | `8.2.3` | `8.0.1` |
| `LatestPatch` | (fails) | `8.0.1` |
| `LatestMinor` | `8.4.5` | `8.4.5` |
| `LatestMajor` | `9.7.8` | `9.7.8` |
| `Disable` | (fails) | (fails) |

Comment on lines +17 to +29
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this should be here as this is an include file that only has a single table. The extra context would be provided by the actual article that uses this include file, if appropriate.

Suggested change
For example, suppose an application requests version `8.0.0`, while the locally available versions are `8.2.0`, `8.2.3`, `8.4.5`, `9.0.0`, `9.0.6`, `9.7.8`.
Then the resolved version is as follows in each case:
| Value | Resolved version | Resolved version if `8.0.1` were also available |
|---------------|------------------|-------------------------------------------------|
| `Minor` | `8.2.3` | `8.0.1` |
| `Major` | `8.2.3` | `8.0.1` |
| `LatestPatch` | (fails) | `8.0.1` |
| `LatestMinor` | `8.4.5` | `8.4.5` |
| `LatestMajor` | `9.7.8` | `9.7.8` |
| `Disable` | (fails) | (fails) |