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.

Sign up for GitHub

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

Jump to bottom

docs: type definition changes are not breaking #585

Merged
merged 3 commits into from
Oct 4, 2024
Merged

docs: type definition changes are not breaking #585

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
350185d
docs: type definition changes are not breaking
samuelmaddock Sep 30, 2024
ebffa71
lint
samuelmaddock Sep 30, 2024
25847cf
docs: clarify runtime vs static compilation
samuelmaddock Oct 3, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions wg-api/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
3 changes: 3 additions & 0 deletions wg-api/best-practices.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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]
> Breaking changes should be that which affects JavaScript runtime usage. If a change affects type definitions which breaks static compilation of a TypeScript app, that is not enough to be considered a breaking change.

### 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?
Expand Down