RELEASE_SCHEDULE.md
webpack follows semantic versioning. This document describes when each kind of release happens and how it is produced.
Bug fixes are not held for the next scheduled release. Once a fix is merged and verified on main, a patch release is published as soon as possible — often the same day. Regressions in a recent release and security fixes take priority over everything else.
Feature work ships on a fixed cadence: a minor release every four weeks, on a Thursday. Everything merged into main before that date goes out with it; anything merged after waits for the next slot rather than delaying the release.
A scheduled release may be skipped when nothing user-facing has landed since the previous one.
The first week of every four-week cycle is a stabilization window: pull requests adding features are not merged for one week after a minor release. Only bug fixes go into main during that week, so a regression reported against the fresh minor can be fixed and patched out on its own.
The point is that the patch releases of that week stay clean. If features were merged straight after a minor, every regression fix would drag whatever features had landed since out with it — a stream of small releases each mixing new behavior into what was meant to be a fix, and each one a new thing to bisect when the next report comes in.
Once the week is over, feature pull requests are merged as usual for the remaining three weeks of the cycle. Approved feature pull requests simply wait during the window; there is no need to close or rebase them.
The cadence above is for feature work. A release is published as soon as the fix is on main, without waiting for the four-week slot or the end of the stabilization window, when it contains:
Such a release carries only the fix and whatever else has already landed; nothing is held back for it and no feature is merged to accompany it.
Major releases are not scheduled. A new major happens only after the roadmap and the other aspects requiring significant changes — breaking changes, the supported Node.js range, migration effort for the ecosystem, and the work needed in loaders, plugins and the documentation — have been discussed publicly and agreed on by the Core Working Group.
If you are proposing a change that requires a major, open a discussion first — see CONTRIBUTING.md.
| Bump | Contents |
|---|---|
patch | Bug fixes, performance improvements, internal refactors, dependency updates. |
minor | New features, new configuration options, new public API — backwards compatible. |
major | Breaking changes to the config schema, the public API, or the supported runtimes. |
Every user-facing pull request carries a changeset declaring its bump level; see the "Adding a Changeset" section of AGENTS.md for the format.
A change that does not affect the published package — repository documentation, CI or tests only — needs no changeset: it is not released on its own and does not appear in the changelog.
Releases are automated with changesets — see .github/workflows/release.yml:
main updates a chore(release): new release pull request that consumes the pending changesets, bumps the version in package.json and writes CHANGELOG.md.So cutting a release means merging the release pull request — the timing of that merge is what the schedule above describes.