Updates for b/382524574 (#12503)

GoogleCloudPlatform · Dec 5, 2024 · e831a6f · e831a6f
1 parent 677f7a7
commit e831a6f
Show file tree

Hide file tree

Showing 8 changed files with 13 additions and 12 deletions.
diff --git a/docs/content/best-practices/deletion-behaviors.md b/docs/content/best-practices/deletion-behaviors.md
@@ -13,7 +13,7 @@ weight: 20
 
 Some resources, such as databases, have a significant risk of unrecoverable data loss if the resource is accidentally deleted due to a change to a ForceNew field. For these resources, the best practice is to add a `deletion_protection` field that prevents the resource from being deleted if enabled.
 
-`deletion_protection` fields  generally need to be added with a default of `false` that can be changed to `true` in the next major release, because adding deletion protection is a [major behavioral change]({{< ref "/develop/breaking-changes/breaking-changes/#resource-level-breaking-changes" >}}). Exceptions to this are:
+`deletion_protection` fields  generally need to be added with a default of `false` that can be changed to `true` in the next major release, because adding deletion protection is a [major behavioral change]({{< ref "/breaking-changes/breaking-changes/#resource-level-breaking-changes" >}}). Exceptions to this are:
 
 - The API has a deletion protection field that defaults to enabled on the API side
 - The `deletion_protection` field is being added at the same time as the resource

diff --git a/docs/content/breaking-changes/_index.md b/docs/content/breaking-changes/_index.md
@@ -0,0 +1,4 @@
+---
+title: "Breaking changes"
+weight: 45
+---
diff --git a/...elop/breaking-changes/breaking-changes.md → ...tent/breaking-changes/breaking-changes.md b/...elop/breaking-changes/breaking-changes.md → ...tent/breaking-changes/breaking-changes.md
@@ -5,6 +5,7 @@ aliases:
 - /docs/content/develop/breaking-changes
 - /reference/breaking-change-detector
 - /develop/breaking-changes
+- /develop/breaking-changes/breaking-changes
 
 ---
 
@@ -25,7 +26,7 @@ comprehensive. Some types of changes that would normally be "breaking" may
 have specific mitigating circumstances that make them non-breaking.
 
 For more information, see
-[Make a breaking change]({{< ref "/develop/breaking-changes/make-a-breaking-change" >}}).
+[Make a breaking change]({{< ref "/breaking-changes/make-a-breaking-change" >}}).
 
 ## Provider-level breaking changes
 

diff --git a/...reaking-changes/make-a-breaking-change.md → ...reaking-changes/make-a-breaking-change.md b/...reaking-changes/make-a-breaking-change.md → ...reaking-changes/make-a-breaking-change.md
@@ -6,13 +6,14 @@ summary: "Guidance on making a breaking changes"
 weight: 20
 aliases:
 - /develop/make-a-breaking-change
+- /develop/breaking-changes/make-a-breaking-change
 ---
 
 # Make a breaking change
 
 A "breaking change" is any change that requires an end user to modify any
 previously-valid configuration after a provider upgrade. For more information,
-see [Types of breaking changes]({{< ref "/develop/breaking-changes" >}}).
+see [Types of breaking changes]({{< ref "/breaking-changes/breaking-changes" >}}).
 
 The `google` and `google-beta` providers are both considered "stable surfaces"
 for the purpose of releases, which means that neither provider allows breaking

diff --git a/docs/content/contribute/review-pr.md b/docs/content/contribute/review-pr.md
@@ -17,7 +17,7 @@ This page provides guidelines for reviewing a Magic Modules pull request (PR).
    1. the features are added in the correct version
       * features only available in beta are not included in the GA google provider.
       * features added to the GA provider are also included in the beta provider -- beta should be a strict superset of GA.
-   1. no [breaking changes]({{< ref "/develop/breaking-changes/make-a-breaking-change" >}}) are introduced without a valid justification. Add the `override-breaking-change` label if there is a valid justification.
+   1. no [breaking changes]({{< ref "/breaking-changes/make-a-breaking-change" >}}) are introduced without a valid justification. Add the `override-breaking-change` label if there is a valid justification.
       * remember to check for changes in default behaviour like changing the flags on delete! 
    1. verify the change **fully** resolves the linked issues, if any. If it does not, change the "Fixes" message to "Part of".
 1. Check the tests added/modified to ensure that:

diff --git a/docs/content/contribution-process.md b/docs/content/contribution-process.md
@@ -29,7 +29,7 @@ This page explains how you can contribute code and documentation to the	`magic-m
    + [Add resource tests]({{< ref "/test/test" >}})
    + [Add a datasource]({{< ref "/develop/add-handwritten-datasource" >}})
    + [Promote to GA]({{< ref "/develop/promote-to-ga" >}})
-   + [Make a breaking change]({{< ref "/develop/breaking-changes/make-a-breaking-change" >}})
+   + [Make a breaking change]({{< ref "/breaking-changes/make-a-breaking-change" >}})
 1. [Generate the providers]({{< ref "/develop/generate-providers" >}}) that include your change.
 1. [Run provider tests locally]({{< ref "/test/run-tests" >}}) that are relevant to the change you made
 1. [Create a pull request (PR)]({{< ref "/contribute/create-pr" >}})

diff --git a/docs/content/develop/breaking-changes/_index.md b/docs/content/develop/breaking-changes/_index.md
diff --git a/docs/content/develop/diffs.md b/docs/content/develop/diffs.md
@@ -19,7 +19,7 @@ The sections below describe in more detail how to address a number of different
 
 ## API returns default value for unset field {#default}
 
-For new fields, if possible, set a client-side default that matches the API default. This will prevent the diff and will allow users to accurately see what the end state will be if the field is not set in their configuration. A client-side default should only be used if the API sets the same default value in all cases and the default value will be stable over time. Changing a client-side default is a [breaking change]({{< ref "/develop/breaking-changes/breaking-changes" >}}).
+For new fields, if possible, set a client-side default that matches the API default. This will prevent the diff and will allow users to accurately see what the end state will be if the field is not set in their configuration. A client-side default should only be used if the API sets the same default value in all cases and the default value will be stable over time. Changing a client-side default is a [breaking change]({{< ref "/breaking-changes/breaking-changes" >}}).
 
 {{< tabs "default_value" >}}
 {{< tab "MMv1" >}}
@@ -299,4 +299,4 @@ func flattenResourceNameFieldName(v interface{}, d *schema.ResourceData, config
 {{< /tab >}}
 {{< /tabs >}}
 
-For other Array fields, convert the field to a Set – this is a [breaking change]({{< ref "/develop/breaking-changes/breaking-changes" >}}) and can only happen in a major release.
+For other Array fields, convert the field to a Set – this is a [breaking change]({{< ref "/breaking-changes/breaking-changes" >}}) and can only happen in a major release.