- Use
npm versionand push. The publish workflow handles the rest. - Create a GitHub Release for the new tag with release notes following the style guide below.
Formatting:
- Use past tense verbs to start the sentence, e.g. "Fixed", "Added", "Removed", ...
- Each bullet point is a sentence (or more), and so ends with a period.
- Package names are in
code, sometimes linked to their https://www.npmjs.com/ page. - Prefer referring to methods and properties via
someInstance.prop, instead ofClassName.prototype.prop. (Never useClassName.propexcept for statics.) - Refer to attributes via
attr="". - Refer to elements via
<element>. - Refer to events via
eventname. - Refer to CSS properties via
'propname'. - Never use the IDL terms "interface", "attribute", or "operation".
- URL schemes are in
code, e.g.data:. - All version numbers get a "v" prefix, e.g. v12.2.0.
- Follow the bullet point with parenthetical GitHub @-mentions when contributed by a non-core team member, e.g. "Fixed foo. (@person)"
Other guidelines:
- Commit messages are primarily for jsdom developers. Release notes are primarily for users. Usually you cannot reuse the commit message.
- Sometimes a single commit may expand to multiple release note entries.
- Do not include commits that have no user-facing impact, e.g. test rolls, refactorings, benchmark additions, etc.
- For regression fixes, note the version in which something regressed.
- Breaking changes get their own section.
- Group in the order "Added", "Removed", "Changed", "Fixed".
- Roughly order changes within those groupings by impact.
- Update the
"engines"field inpackage.json. - Update
.github/workflows/ci.yml.