docs: type definition changes are not breaking

electron · Sep 30, 2024 · 350185d · 350185d
1 parent a632834
commit 350185d
Show file tree

Hide file tree

Showing 2 changed files with 4 additions and 0 deletions.
diff --git a/wg-api/README.md b/wg-api/README.md
@@ -26,6 +26,7 @@ Oversees public API design based on project principles.
   | <img src="https://github.com/zcbenz.png" width=100 alt="@zcbenz">  | Cheng Zhao [@zcbenz](https://github.com/zcbenz) | Member | JST (Nagoya) |
 
 </details>
+
 ## Areas of Responsibility
 
 * Define the process for which API changes are reviewed and approved.

diff --git a/wg-api/best-practices.md b/wg-api/best-practices.md
@@ -12,6 +12,9 @@ API changes which alter existing behavior can cause apps to break unexpectedly w
 
 If the behavior must change to support the feature, the change should be listed in [the breaking changes document](https://github.com/electron/electron/blob/main/docs/breaking-changes.md). Additionally, consider whether the change can be introduced in a way which permits a deprecation cycle, for instance introducing the new API under a new name and deprecating the old name while keeping the behavior unchanged for apps using the API under the old name.
 
+> [!NOTE]  
+> Changes that only affect TypeScript type definitions are not considered breaking changes.
+
 ### How will this API be extended in the future?
 
 What additional changes can you imagine being made to this API in the future? Are there any features that are not in the first version of a change you’re making that you would like to include in the future?