@namroodinc/liquid-editorial 0.1.4 → 0.1.5

package/AGENTS.md

@@ -4,7 +4,7 @@
 
 Add a decision document for every change going forward.
 
-Every releasable change set must increment the package version and update the corresponding version entry in `UPGRADING.md` with changes, adoption steps, compatibility notes, and verification steps for agents in consuming projects. Start with `0.1.3` after `0.1.2`; subsequent change sets increment the patch version unless a minor or major release is explicitly requested. Related edits in one change set share a version. Keep the manifest and lockfile versions aligned and include this file and `UPGRADING.md` in the package.
+Every releasable change set must update the `Unreleased` section in `UPGRADING.md` with changes, adoption steps, compatibility notes, and verification steps for agents in consuming projects. Related edits share that section. Leave version increments to `.github/workflows/release.yml`: every push to `main` automatically bumps the patch version, versions the upgrade notes, validates, commits the release files, and publishes to npm. Keep the manifest and lockfile versions aligned and include this file and `UPGRADING.md` in the package.
 
 ## Using the installed package
 

package/README.md

@@ -99,7 +99,7 @@ Storybook is the component catalogue and documentation surface. Stories and test
 
 ## Publishing
 
-Publishing a GitHub Release runs [the release workflow](.github/workflows/release.yml): it checks the release version, runs `npm run validate`, then publishes `@namroodinc/liquid-editorial` to npm. The release tag must be `v` followed by the exact version in both `package.json` and `package-lock.json`. Stable versions publish to `latest`; versions such as `0.2.0-beta.1` must be marked as GitHub prereleases and publish to `next`. Branch pushes and draft releases run no publishing step.
+Merge a PR into `main` to publish a release. Every push to `main` runs [the release workflow](.github/workflows/release.yml), which installs dependencies, bumps the patch version, moves the `Unreleased` upgrade notes under that version, and runs `npm run validate`. It then commits the version files and guide back to `main` and publishes `@namroodinc/liquid-editorial` to npm under `latest`. All commands run in GitHub Actions; contributors do not run local release commands or create GitHub Releases or tags. Other branches and pull requests do not publish.
 
 ### One-time npm setup
 
@@ -119,18 +119,13 @@ npm trust github @namroodinc/liquid-editorial --repo namroodinc/liquid-editorial
 
 npm requires two-factor verification for this setup. The workflow subsequently authenticates through OIDC without an `NPM_TOKEN` secret. Complete the first workflow publish within two days of adding the trusted publisher to avoid configuration expiry. See [npm's trusted publishing guide](https://docs.npmjs.com/trusted-publishers/) for the current setup requirements.
 
-### Create a release
+### Release a change
 
-For the next patch release after `0.1.0`:
+Add the change's adoption, compatibility, and verification notes under `Unreleased` in `UPGRADING.md`, then merge the PR to `main`. The workflow handles the version bump; for example, `0.1.4` becomes `0.1.5`. Pull the generated version commit before continuing local work.
 
-```sh
-npm version patch --no-git-tag-version
-git add package.json package-lock.json
-git commit -m "chore: release v0.1.1"
-git push origin main
-```
+Follow **Publish to npm** in GitHub Actions to check the result. Runs are serialized, and the bot's version commit uses `GITHUB_TOKEN`, which does not trigger another workflow run.
 
-On GitHub, publish a Release with tag `v0.1.1` targeting that commit. GitHub can create the tag when publishing the release. For later releases, use the version produced by `npm version`; for a prerelease, use a version such as `0.2.0-beta.1` and select **Set as a pre-release**. Publishing an already-published npm version fails, so every release needs a new version.
+Failures stop the workflow. If validation or the version push fails, npm publishing does not run. If publishing fails after the version commit is pushed, that commit stays on `main`; rerunning the workflow bumps to the next patch version. The workflow does not roll back versions or create GitHub Releases or tags.
 
 ## License
 

package/UPGRADING.md

@@ -1,5 +1,26 @@
 # Liquid Editorial upgrades
 
+## Unreleased
+
+## 0.1.5
+
+### Changes
+
+- Pushes to `main`, including merged PRs, now automatically bump the patch version and publish the package to npm after validation.
+- The release workflow moves these notes under the new version and commits the version files and guide back to `main`.
+
+### Adoption
+
+Library contributors add upgrade guidance here and merge their changes to `main`. GitHub Actions handles versioning, validation, and publishing; there are no local npm release commands or manual GitHub Releases to create. Pull the generated version commit before continuing local work. Consuming applications can update the dependency as usual.
+
+### Compatibility
+
+The workflow publishes stable patch releases under `latest`. Creating a GitHub Release no longer triggers publishing. Component APIs are unchanged.
+
+### Verification
+
+Check the `Publish to npm` workflow in GitHub Actions and confirm that the new version appears on the npm package page. The workflow runs the existing full validation before committing and publishing.
+
 ## 0.1.3
 
 ### Changes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@namroodinc/liquid-editorial",
-  "version": "0.1.4",
+  "version": "0.1.5",
   "description": "A bold, accessible React component library for editorial products.",
   "author": "Namrood Inc",
   "license": "MIT",