2024-09-18 08:58:07 +00:00
|
|
|
|
import { _ as _export_sfc, c as createElementBlock, o as openBlock, a8 as createStaticVNode } from "./chunks/framework.Clpp4x2N.js";
|
2024-08-26 05:15:18 +00:00
|
|
|
|
const __pageData = JSON.parse('{"title":"Breaking Changes","description":"","frontmatter":{},"headers":[],"relativePath":"breaking_changes.md","filePath":"breaking_changes.md"}');
|
|
|
|
|
|
const _sfc_main = { name: "breaking_changes.md" };
|
|
|
|
|
|
const _hoisted_1 = /* @__PURE__ */ createStaticVNode('<h1 id="breaking-changes" tabindex="-1">Breaking Changes <a class="header-anchor" href="#breaking-changes" aria-label="Permalink to "Breaking Changes""></a></h1><p>This document describes QMK's Breaking Change process. A Breaking Change is any change which modifies how QMK behaves in a way that in incompatible or potentially dangerous. We limit these changes so that users can have confidence that updating their QMK tree will not break their keymaps.</p><p>This also includes any keyboard moves within the repository.</p><p>The breaking change period is when we will merge PRs that change QMK in dangerous or unexpected ways. There is a built-in period of testing so we are confident that any problems caused are rare or unable to be predicted.</p><p>Practically, this means QMK merges the <code>develop</code> branch into the <code>master</code> branch on a 3-month cadence.</p><h2 id="what-has-been-included-in-past-breaking-changes" tabindex="-1">What has been included in past Breaking Changes? <a class="header-anchor" href="#what-has-been-included-in-past-breaking-changes" aria-label="Permalink to "What has been included in past Breaking Changes?""></a></h2><ul><li><a href="./ChangeLog/20240825">2024 Aug 25</a></li><li><a href="./ChangeLog/20240526">2024 May 26</a></li><li><a href="./ChangeLog/20240225">2024 Feb 25</a></li><li><a href="./breaking_changes_history">Older Breaking Changes</a></li></ul><h2 id="when-is-the-next-breaking-change" tabindex="-1">When is the next Breaking Change? <a class="header-anchor" href="#when-is-the-next-breaking-change" aria-label="Permalink to "When is the next Breaking Change?""></a></h2><p>The next Breaking Change is scheduled for November 24, 2024.</p><h3 id="important-dates" tabindex="-1">Important Dates <a class="header-anchor" href="#important-dates" aria-label="Permalink to "Important Dates""></a></h3><ul><li>2024 Aug 25 - <code>develop</code> is tagged with a new release version. Each push to <code>master</code> is subsequently merged to <code>develop</code> by GitHub actions.</li><li>2024 Oct 27 - <code>develop</code> closed to new PRs.</li><li>2024 Oct 27 - Call for testers.</li><li>2024 Nov 10 - Last day for merges -- after this point <code>develop</code> is locked for testing and accepts only bugfixes</li><li>2024 Nov 17 - <code>develop</code> is locked, only critical bugfix PRs merged.</li><li>2024 Nov 22 - <code>master</code> is locked, no PRs merged.</li><li>2024 Nov 24 - Merge <code>develop</code> to <code>master</code>.</li><li>2024 Nov 24 - <code>master</code> is unlocked. PRs can be merged again.</li></ul><h2 id="what-changes-will-be-included" tabindex="-1">What changes will be included? <a class="header-anchor" href="#what-changes-will-be-included" aria-label="Permalink to "What changes will be included?""></a></h2><p>To see a list of breaking changes merge candidates you can look at the <a href="https://github.com/qmk/qmk_firmware/pulls?q=is%3Aopen+label%3Acore+is%3Apr" target="_blank" rel="noreferrer"><code>core</code> label</a>. This label is applied whenever a PR is raised or changed, but only if the PR includes changes to core areas of QMK Firmware. A PR with that label applied is not guaranteed to be merged in the current cycle. New changes might be added between now and when <code>develop</code> is closed, and it is generally the responsibility of the submitter to handle conflicts. There is also another label used by QMK Collaborators -- <code>breaking_change_YYYYqN</code> -- which signifies to maintainers that it is a strong candidate for inclusion, and should be prioritized for review.</p><p>If you want your breaking change to be included in this round you need to create a PR and have it accepted by QMK Collaborators before <code>develop</code> closes. After <code>develop</code> closes, new submissions will be deferred to the next breaking changes cycle.</p><p>The simpler your PR is, the easier it is for maintainers to review, thus a higher like
|
|
|
|
|
|
const _hoisted_38 = [
|
|
|
|
|
|
_hoisted_1
|
|
|
|
|
|
];
|
|
|
|
|
|
function _sfc_render(_ctx, _cache, $props, $setup, $data, $options) {
|
|
|
|
|
|
return openBlock(), createElementBlock("div", null, _hoisted_38);
|
|
|
|
|
|
}
|
|
|
|
|
|
const breaking_changes = /* @__PURE__ */ _export_sfc(_sfc_main, [["render", _sfc_render]]);
|
|
|
|
|
|
export {
|
|
|
|
|
|
__pageData,
|
|
|
|
|
|
breaking_changes as default
|
|
|
|
|
|
};
|
