You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For each breaking change listed in the Electron docs for the new major version:
145
147
146
148
1.**Identify** whether the breaking change affects any API used in this codebase.
147
-
2.**If affected**, apply the necessary code fix:
148
-
- Search the codebase for all usages of the affected API.
149
-
- Update the code to use the new API or pattern as prescribed by the Electron breaking changes doc.
150
-
- Ensure backward compatibility with the minimum supported Electron version (currently ^35.0.0) — use feature detection or version checks when the old API is removed and a polyfill is needed.
149
+
2.**If affected**, describe the required code fix and which files need modification.
151
150
3.**If not affected**, note it and move on.
152
151
153
152
**Common breaking change categories to watch for:**
@@ -159,6 +158,24 @@ For each breaking change listed in the Electron docs for the new major version:
159
158
- New required permissions or security policy changes
160
159
- Deprecated APIs that are now removed
161
160
161
+
#### Present findings and wait for approval
162
+
163
+
After completing the analysis, present a summary table to the invoker:
164
+
165
+
| Breaking change | Affected? | Proposed fix |
166
+
| --- | --- | --- |
167
+
| (change description) | Yes / No | (fix description or "N/A") |
168
+
169
+
**STOP here and wait for the invoker's explicit go-ahead before making any file changes.** If the invoker requests modifications to the proposed approach, incorporate their feedback before proceeding.
170
+
171
+
#### Apply breaking change fixes (after approval)
172
+
173
+
Once approved, for each affected breaking change:
174
+
175
+
- Search the codebase for all usages of the affected API.
176
+
- Update the code to use the new API or pattern as prescribed by the Electron breaking changes doc.
177
+
- Ensure backward compatibility with the minimum supported Electron version documented in docs/learning/SupportedPlatforms.md — use feature detection or version checks when the old API is removed and a polyfill is needed.
178
+
162
179
If a breaking change requires a non-trivial migration (e.g., architectural changes), document the issue in the report. If triggered from a GitHub issue, add a comment to the issue describing the blocker and wait for guidance. Otherwise, ask the invoker before proceeding with the fix.
163
180
164
181
### Step 3.5: Update `@itwin/electron-authorization` if needed
@@ -290,10 +307,13 @@ gh pr create \
290
307
--head electron-<NEW_MAJOR> \
291
308
--title "Add support for Electron <NEW_MAJOR>" \
292
309
--body "$(cat <<'EOF'
293
-
Adds support for Electron <NEW_MAJOR>.
294
-
295
310
### Breaking changes review
296
-
<Include the breaking changes assessment here — list each change with "affected" / "not affected" status>
311
+
312
+
<Include the breaking changes assessment table from Step 3 here>
313
+
314
+
### Notes
315
+
316
+
<Include any relevant notes, e.g. unmet peer dependencies>
297
317
298
318
See [Electron <NEW_MAJOR> release blog](https://www.electronjs.org/blog/electron-<NEW_MAJOR>-0) for details.
"comment": "Added batching while writing instance patches to the file during semantic rebase. Also reduced the $meta field in instance patches to include only the necessary properties and skip unnecessary ones.",
0 commit comments