diff --git a/docs/api/api-versioning-strategy.md b/docs/api/api-versioning-strategy.md index 77e645ebbb0a..1439d89a34b9 100644 --- a/docs/api/api-versioning-strategy.md +++ b/docs/api/api-versioning-strategy.md @@ -88,17 +88,17 @@ If you attempt to invoke an experimental API without specifying the `X-SailPoint ## Release schedule -SailPoint will introduce an annual release which includes both public and experimental APIs. Each yearly version will be named according to its release year. For instance, if the release occurs in 2025, the version will be designated as v2025. +SailPoint will introduce an annual release that includes both public and experimental APIs. Each yearly version will be named according to its release year. For instance, if the release occurs in 2025, the version will be designated as v2025. -Each annual release will be accompanied by an experimental release if there is at least one breaking change introduced in the current annual release. This experimental release will be named after the next year. For example, if the current year is 2025, the experimental version will be named v2026. Any breaking changes to public endpoints in a public version throughout the year will be introduced in the experimental version. +Each annual release may be accompanied by an experimental release if it introduces at least one breaking change. For example, if the annual release is v2025 and includes breaking changes, those changes will be introduced as experimental APIs in v2026. When a new annual release is introduced, non-deprecated endpoints will generally be transferred to the new release without modifications. As a result, the same endpoint will usually be able to be accessed via both the old and new versions. Only the latest public release will receive new functionality. If at anytime throughout the year a experimental API is deemed ready for production, it will be released into the current year’s public version, but not previous years. Annual release versions will typically be supported for 3 years and then remain operational for an additional 2-year transition period, unless otherwise noted or an exception applies. Customers will be expected to move to the latest public release during those two years. Customers seeking support for an annual release that is over 3 years old will be asked to transition to a newer version. -The following image demonstrates the support model for public and experimental releases. The green bars represent how long an annual release version will be supported by our support team. When a annual release is older than three years, it may still remain operational, but it is no longer supported. The blue bars represent experimental releases which are available for one year in the preview state before being changed to a production release. +The following image demonstrates the support model for public and experimental releases. The green bars represent how long an annual release version will be supported by our support team. When a annual release is older than three years, it may still remain operational, but it is no longer supported. The blue bars represent an experimental release that introduces breaking changes, if any exist. -![Versioning Timeline](./img/api-versioning-timeline.jpg) +![Versioning Timeline](./img/api-versioning-timeline.png) ## Deprecations diff --git a/docs/api/beta/api-versioning-strategy.md b/docs/api/beta/api-versioning-strategy.md index 7ebdacfdcc32..822f8f42cec8 100644 --- a/docs/api/beta/api-versioning-strategy.md +++ b/docs/api/beta/api-versioning-strategy.md @@ -90,15 +90,15 @@ If you attempt to invoke an experimental API without specifying the `X-SailPoint SailPoint will introduce an annual release which includes both public and experimental APIs. Each yearly version will be named according to its release year. For instance, if the release occurs in 2025, the version will be designated as v2025. -Each annual release will be accompanied by an experimental release if there is at least one breaking change introduced in the current annual release. This experimental release will be named after the next year. For example, if the current year is 2025, the experimental version will be named v2026. Any breaking changes to public endpoints in a public version throughout the year will be introduced in the experimental version. +Each annual release may be accompanied by an experimental release if there is at least one breaking change introduced in the current annual release. For example, if the annual release is v2025 and breaking changes would be introduced, those breaking changes will be introduced as v2026 experimental APIs. When a new annual release is introduced, non-deprecated endpoints will generally be transferred to the new release without modifications. As a result, the same endpoint will usually be able to be accessed via both the old and new versions. Only the latest public release will receive new functionality. If at anytime throughout the year a experimental API is deemed ready for production, it will be released into the current year’s public version, but not previous years. Annual release versions will typically be supported for 3 years and then remain operational for an additional 2-year transition period, unless otherwise noted or an exception applies. Customers will be expected to move to the latest public release during those two years. Customers seeking support for an annual release that is over 3 years old will be asked to transition to a newer version. -The following image demonstrates the support model for public and experimental releases. The green bars represent how long an annual release version will be supported by our support team. When a annual release is older than three years, it may still remain operational, but it is no longer supported. The blue bars represent experimental releases which are available for one year in the preview state before being changed to a production release. +The following image demonstrates the support model for public and experimental releases. The green bars represent how long an annual release version will be supported by our support team. When a annual release is older than three years, it may still remain operational, but it is no longer supported. The blue bars represents an experimental release that introduces breaking changes, if any exist. -![Versioning Timeline](../img/api-versioning-timeline.jpg) +![Versioning Timeline](../img/api-versioning-timeline.png) ## Deprecations diff --git a/docs/api/img/api-versioning-timeline.jpg b/docs/api/img/api-versioning-timeline.jpg deleted file mode 100644 index 870fc6c5294c..000000000000 Binary files a/docs/api/img/api-versioning-timeline.jpg and /dev/null differ diff --git a/docs/api/img/api-versioning-timeline.png b/docs/api/img/api-versioning-timeline.png new file mode 100644 index 000000000000..5f2b1d7292d6 Binary files /dev/null and b/docs/api/img/api-versioning-timeline.png differ diff --git a/docs/api/v2024/api-versioning-strategy.md b/docs/api/v2024/api-versioning-strategy.md index 621ed71bead7..dfc1ceb22c5a 100644 --- a/docs/api/v2024/api-versioning-strategy.md +++ b/docs/api/v2024/api-versioning-strategy.md @@ -88,17 +88,17 @@ If you attempt to invoke an experimental API without specifying the `X-SailPoint ## Release schedule -SailPoint will introduce an annual release which includes both public and experimental APIs. Each yearly version will be named according to its release year. For instance, if the release occurs in 2025, the version will be designated as v2025. +SailPoint will introduce an annual release that includes both public and experimental APIs. Each yearly version will be named according to its release year. For instance, if the release occurs in 2025, the version will be designated as v2025. -Each annual release will be accompanied by an experimental release if there is at least one breaking change introduced in the current annual release. This experimental release will be named after the next year. For example, if the current year is 2025, the experimental version will be named v2026. Any breaking changes to public endpoints in a public version throughout the year will be introduced in the experimental version. +Each annual release may be accompanied by an experimental release if it introduces at least one breaking change. For example, if the annual release is v2025 and includes breaking changes, those changes will be introduced as experimental APIs in v2026. When a new annual release is introduced, non-deprecated endpoints will generally be transferred to the new release without modifications. As a result, the same endpoint will usually be able to be accessed via both the old and new versions. Only the latest public release will receive new functionality. If at anytime throughout the year a experimental API is deemed ready for production, it will be released into the current year’s public version, but not previous years. Annual release versions will typically be supported for 3 years and then remain operational for an additional 2-year transition period, unless otherwise noted or an exception applies. Customers will be expected to move to the latest public release during those two years. Customers seeking support for an annual release that is over 3 years old will be asked to transition to a newer version. -The following image demonstrates the support model for public and experimental releases. The green bars represent how long an annual release version will be supported by our support team. When a annual release is older than three years, it may still remain operational, but it is no longer supported. The blue bars represent experimental releases which are available for one year in the preview state before being changed to a production release. +The following image demonstrates the support model for public and experimental releases. The green bars represent how long an annual release version will be supported by our support team. When a annual release is older than three years, it may still remain operational, but it is no longer supported. The blue bars represents an experimental release that introduces breaking changes, if any exist. -![Versioning Timeline](../img/api-versioning-timeline.jpg) +![Versioning Timeline](../img/api-versioning-timeline.png) ## Deprecations diff --git a/docs/api/v3/api-versioning-strategy.md b/docs/api/v3/api-versioning-strategy.md index 90fe60420f87..f6e0b76aa58b 100644 --- a/docs/api/v3/api-versioning-strategy.md +++ b/docs/api/v3/api-versioning-strategy.md @@ -88,17 +88,17 @@ If you attempt to invoke an experimental API without specifying the `X-SailPoint ## Release schedule -SailPoint will introduce an annual release which includes both public and experimental APIs. Each yearly version will be named according to its release year. For instance, if the release occurs in 2025, the version will be designated as v2025. +SailPoint will introduce an annual release that includes both public and experimental APIs. Each yearly version will be named according to its release year. For instance, if the release occurs in 2025, the version will be designated as v2025. -Each annual release will be accompanied by an experimental release if there is at least one breaking change introduced in the current annual release. This experimental release will be named after the next year. For example, if the current year is 2025, the experimental version will be named v2026. Any breaking changes to public endpoints in a public version throughout the year will be introduced in the experimental version. +Each annual release may be accompanied by an experimental release if it introduces at least one breaking change. For example, if the annual release is v2025 and includes breaking changes, those changes will be introduced as experimental APIs in v2026. When a new annual release is introduced, non-deprecated endpoints will generally be transferred to the new release without modifications. As a result, the same endpoint will usually be able to be accessed via both the old and new versions. Only the latest public release will receive new functionality. If at anytime throughout the year a experimental API is deemed ready for production, it will be released into the current year’s public version, but not previous years. Annual release versions will typically be supported for 3 years and then remain operational for an additional 2-year transition period, unless otherwise noted or an exception applies. Customers will be expected to move to the latest public release during those two years. Customers seeking support for an annual release that is over 3 years old will be asked to transition to a newer version. -The following image demonstrates the support model for public and experimental releases. The green bars represent how long an annual release version will be supported by our support team. When a annual release is older than three years, it may still remain operational, but it is no longer supported. The blue bars represent experimental releases which are available for one year in the preview state before being changed to a production release. +The following image demonstrates the support model for public and experimental releases. The green bars represent how long an annual release version will be supported by our support team. When a annual release is older than three years, it may still remain operational, but it is no longer supported. The blue bars represents an experimental release that introduces breaking changes, if any exist. -![Versioning Timeline](../img/api-versioning-timeline.jpg) +![Versioning Timeline](../img/api-versioning-timeline.png) ## Deprecations