+2
-2
@@ -171,9 +171,9 @@ Exported types can be marked with either `@public`, `@alpha` or `@beta` release
|
||||
|
||||
If a package does not have this configuration, then all exported types are considered stable, even if they are marked as `@alpha` or `@beta`.
|
||||
|
||||
#### Changes that are not Considered Breaking
|
||||
#### Changes that are Not Considered Breaking
|
||||
|
||||
There are a few exceptions that are not considered breaking in the [versioning policy](https://backstage.io/docs/overview/versioning-policy),
|
||||
There are a few exceptions that are not considered breaking in the [versioning policy](https://backstage.io/docs/overview/versioning-policy#changes-that-are-not-considered-breaking),
|
||||
primarily regarding Utility APIs and Backend Service interfaces (referred to "contracts" below) that are supplied by the
|
||||
Backstage core packages.
|
||||
|
||||
|
||||
@@ -120,7 +120,7 @@ For packages at version `1.0.0` or above, the following policy also applies:
|
||||
changes without a deprecation period, but the changes must still adhere to
|
||||
semver.
|
||||
|
||||
### Changes that are not Considered Breaking
|
||||
### Changes that are Not Considered Breaking
|
||||
|
||||
There are a few changes that would typically be considered breaking changes, but
|
||||
that we make exceptions for. This is both to be able to evolve the project more
|
||||
|
||||
Reference in New Issue
Block a user