규칙 13.10

A change that keeps a program compiling and makes it compute something else must ship in two steps, and the second must come no earlier than the next breaking release after the first step’s release was published (the next minor before 1.0.0, the next major after it). First, a published release must report every affected line as a category: 'warning' diagnostic behind the opt-in deprecation option (compile(src, { deprecations: true }), tshc check --deprecations), naming the edit that keeps today’s meaning, with no emitted byte moved with the option on or off. Then the default changes, the warning and its code are retired, a ### Changed entry names the old meaning, the new one and the one-line edit that keeps the old, and every example golden is re-baked and reviewed. The window is counted in published releases. From 1.0.0, a spelling or an export that will be removed must get the same window: the spelling warns under the same option, and the export carries @deprecated in its JSDoc naming its replacement.