Microsoft/bcquality
1
0
Fork 0
mirror of https://github.com/microsoft/BCQuality.git synced 2026-08-06 17:36:53 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
bcquality/microsoft/knowledge/breaking-changes/unreleased-symbol-change-is-not-a-breaking-change.md
wenjiefan 9cc5627f42 Move false-positive guards from skills into knowledge files 
Keep review skills slim (finders/appliers). The FP guards and released-baseline preconditions previously embedded in leaf skills become negative-clarification knowledge articles in their domains, and the agent-findings policy edits to al-ui/al-privacy are reverted to main. Adds 6 knowledge files: error-handling (page-boolean-triggers-default-to-true), ui (bound-page-field-inherits-source-field-tooltip), performance (calcfields-in-both-getrecord-triggers-is-not-redundant, page-effective-filter-may-live-outside-the-diff), breaking-changes (unreleased-symbol-change-is-not-a-breaking-change), upgrade (unreleased-schema-change-needs-no-upgrade-path).
2026-07-17 09:58:16 +02:00

1.6 KiB
Raw Blame History

bc-version domain keywords technologies countries application-area
all
breaking-changes
released-baseline
unreleased
rename
renumber
obsolete
api-stability
false-positive
al
w1
all

Changing an unreleased symbol is not a breaking change

Description

Breaking-change rules protect contracts that have already shipped to customers or are exposed to external extensions. A symbol — an object, field, key, enum value, or procedure — that is new in this app, was introduced and then changed within the same still-unreleased development cycle, or belongs to an app that has no released version yet, can be renamed, renumbered, or removed freely. There is no shipped contract to break, so the change is not a breaking change.

Release status is established from the diff, the app's app.json version, or a released baseline. An app whose app.json version has no corresponding released baseline (for example a 1.0.0.0 app that has never shipped) has no protected surface.

Best Practice

Before treating a rename, renumber, or removal as breaking, establish that the affected symbol was present in a released baseline. Do not flag changes to symbols that are new in the current unreleased cycle or that belong to an app with no released version. When release status cannot be established from the diff, app.json, or a released baseline, omit the finding rather than assert a break.

Anti Pattern

Reporting a breaking change for a rename, renumber, or removal without confirming the symbol shipped in a released version — for example flagging a break on an app whose app.json version has no released baseline.