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

docs: Create BREAKING_CHANGE_AND_DEPRECATION.md #1399

Merged
merged 10 commits into from
May 9, 2024
45 changes: 45 additions & 0 deletions BREAKING_CHANGE_AND_DEPRECATION.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
# Breaking changes and deprecations

Breaking changes are defined as a change to any of the following that causes installation errors or
unexpected runtime behavior after upgrading to the next stable minor version of Ratify:
- Verification API
- Verification result and schema
- Default configuration value
- User facing plugin interfaces

## Stability levels
- Generally available features should not be removed from that version or have its behavior significantly changed to avoid breaking existing users.
- Beta or pre-release versions may introduce breaking changes without deprecation notice.
- Alpha or experimental API versions may change in runtime behaviour without prior change and deprecation notice.

The following features are currently in experimental:
- [Dynamic plugin](https://ratify.dev/docs/reference/dynamic-plugins)
- [High Availability](https://ratify.dev/docs/quickstarts/ratify-high-availability)

## Process for applying breaking changes
- A deprecation notice must be posted as part of a release.
- The PR containing the breaking changes should contain a "!" to indicate this is breaking change. E.g. feat! , fix!
- Breaking changes should be listed before new features in the release notes
- Create a issue to help customer to mitigate the change
Copy link
Collaborator

Choose a reason for hiding this comment

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

is this issue for helping customers migrate to the breaking change?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

note: the mitigation steps must be available at the time of release


## Deprecations
Deprecations can apply to:
susanshi marked this conversation as resolved.
Show resolved Hide resolved
- CRDs
- Experimental Features
- Plugins
- User facing Interfaces
- Configuration Values
- Cli Usage and Configuration
- Verification Schema

susanshi marked this conversation as resolved.
Show resolved Hide resolved
## Process for deprecation

- A deprecation notice must be posted as part of the release notes.
- Documentation should mark the feature as deprecated and redirect user to the alternative implementation.

## Attribution

The specification release process was created using content and verbiage from the following specifications:
- [Kubernetes Deprecation Policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)
- [Dapr reference](https://docs.dapr.io/operations/support/breaking-changes-and-deprecations/)

Loading