@pearpages/heatmap 0.4.1 → 0.4.2

package/README.md

@@ -9,7 +9,7 @@
 
 A GitHub-style contribution heatmap as a React component. Themeable through CSS custom
 properties, localised through `Intl`, dark-mode ready, and correct in every time zone.
-No runtime dependencies: 3.3 kB gzipped, plus 1.9 kB of CSS.
+No runtime dependencies: 3.3 kB gzipped, plus 2.1 kB of CSS.
 
 **[Live demo](https://heatmap.pearpages.com)**
 
@@ -300,6 +300,12 @@ weeks Monday to Sunday, so a translated heatmap that still starts on Sunday read
 wrong. It defaults to `0` (Sunday, the GitHub convention), and the component picks the
 order of its day labels up from the data.
 
+## What's new in 0.4.2
+
+**No code changes.** The README now gives the stylesheet's size as 2.1 kB gzipped, up
+from the 1.9 kB it stated before 0.4.0's custom properties. From this release on, GitHub
+Releases are created by the publish workflow from these notes.
+
 ## What's new in 0.4.1
 
 **No empty table header.** The corner cell above the day-name column was an empty `<th>`,
@@ -386,19 +392,23 @@ game:
 
 | Trigger | Workflow | Effect |
 | --- | --- | --- |
+| Pull request to `main` | `.github/workflows/ci.yml` | Runs the tests, lint, build and package checks. Deploys and publishes nothing |
 | Push to `main` | `.github/workflows/deploy.yml` | Runs the tests, builds the library + `demo/`, deploys to GitHub Pages. **Never touches npm.** |
-| Push a `v*` tag | `.github/workflows/publish.yml` | Builds and publishes to npm with provenance |
+| Push a `v*` tag | `.github/workflows/publish.yml` | Builds and publishes to npm with provenance, then creates the GitHub Release |
 
 So you can push to `main` freely — nothing reaches npm until a `v*` tag is pushed.
 
 ### The happy path
 
+Write a `## What's new in X.Y.Z` section in this README and commit it — it becomes the
+GitHub Release notes. Then:
+
 ```bash
 npm version minor          # bumps package.json, commits, and tags vX.Y.Z
 git push --follow-tags     # pushes main (deploys the demo) and the tag (publishes to npm)
 ```
 
-### Four things that are easy to get wrong
+### Five things that are easy to get wrong
 
 1. **The tag name does not set the published version.** `publish.yml` just runs
    `npm publish`, which reads the version out of `package.json`. Tagging `v0.3.0` while
@@ -415,3 +425,7 @@ git push --follow-tags     # pushes main (deploys the demo) and the tag (publish
    renders the version read from the root `package.json`, and the Pages deploy runs on
    push to `main`. The site therefore shows the bumped version as soon as the bump commit
    lands — before the tag exists, and before npm has anything.
+5. **No "What's new" section, no release.** `publish.yml` takes the release notes from
+   `## What's new in X.Y.Z` (exact version, exact heading) and fails before `npm publish`
+   when it is missing. Add the section and push a new version; a failed tag cannot be
+   re-pushed as-is without deleting it first.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pearpages/heatmap",
-  "version": "0.4.1",
+  "version": "0.4.2",
   "description": "GitHub-style contribution heatmap as a React component.",
   "keywords": [
     "react",