feat: updates to several AIPs

aip/general/0180.md

@@ -64,6 +64,11 @@ However, keep the following guidelines in mind when doing this:
     resources.
   - Any field being populated by clients **must** have a default behavior
     matching the behavior before the field was introduced.
+    - This can be tricky to do in some case. For example, adding pagination
+      after the fact where previously all items were returned (i.e. `page_size`
+      is infinite, which is not advised). If the default for the new `page_size`
+      field is _less_ than what was previously returned, older clients will
+      incorrectly assume all results were returned.
   - Any field previously populated by the server **must** continue to be
     populated, even if it introduces redundancy.
 - For enum values specifically, be aware that it is possible that user code
@@ -113,6 +118,15 @@ Existing fields and messages **must not** have their type changed, even if the
 new type is wire-compatible, because type changes alter generated code in a
 breaking way.
 
+### Changing string length
+
+APIs **should** forward declare the upper bound of expected size and/or the
+limit (if accepted as input) in field documentation. APIs **should** avoid
+changing this and **should** treat expected size upper bound increases as
+incompatible changes (see [Changing resource names](#changing-resource-names) as
+an example). APIs **may** pad out values with filler characters if reserving a
+consistent size is necessary, but this **must** be documented if done.
+
 ### Changing resource names
 
 A resource **must not** change its [name][aip-122].
@@ -245,8 +259,21 @@ version.
 - For compatibility around field presence changes, see [AIP-149][].
 - For compatibility around resource types, see [AIP-123][].
 
+## Rationale
+
+### Risk of string length changes
+
+End users may store resource properties, like the `name`, in a dedicated
+database column with a limited length. If the service starts returning values
+for the `name` that are twice the originally documented/observed length, this
+may unexpectedly break the customer's database. Furthermore, string properties
+that appear in URLs (incl. query parameters) are especially likely to have
+client-side limits, making them more sensitive to length changes.
+
 ## Changelog
 
+- **2025-10-03**: Added guidance for string length changes and an example for
+                  carefully adding components.
 - **2024-08-07**: Added reference to resource type compatibility.
 - **2024-06-05**: Added reference to field presence compatibility.
 - **2023-07-26**: Added reference to field behavior compatibility.