Skip to content

Prepare the 0.1.0 release: version path, changeset, examples and metadata - #7

Merged
NSchatz merged 1 commit into
mainfrom
release-0.1-prep
Sep 25, 2026
Merged

NSchatz merged 1 commit into
mainfrom
release-0.1-prep

Conversation

@NSchatz

@NSchatz NSchatz commented Sep 25, 2026

Copy link
Copy Markdown
Contributor

Prepares the first publish of @cosyte/dates at 0.1.0 on the pipeline #6 added. Merging this opens the "Version Packages" pull request; merging that one, and approving the release environment, publishes.

The version path, and why

package.json goes from 0.1.0 to 0.0.0, and .changeset/first-release.md declares a minor bump, so changeset version in the Version Packages pull request produces 0.1.0 the standard way.

What cosyte/.github scripts/release-notes.mjs prepare requires: it derives notes, and sets is-release=true, only for a version commit that moves package.json off a DIFFERENT version while deleting the changesets it consumed (findVersionCommit plus the consumed diff). 0.1.0 is the only version this repository's history has carried, so every run classifies HEAD never-versioned and withholds the publish forever; a changeset on top of it would ship 0.1.1 (patch) or 0.2.0 (minor), never 0.1.0.

From 0.0.0, measured by running the shared scripts against this branch and a simulated Version Packages commit on top of it:

commit prepare verdict what the workflow does
this PR's merge (0.1.0 to 0.0.0) version-reverted, is-release=false, exit 0 Verify ladder, then changesets/action opens the Version PR
the Version PR's merge (0.0.0 to 0.1.0, changeset consumed) is-release=true, notes derived from 1 changeset changelog-check.mjs --version 0.1.0: pass (## 0.1.0 at line 3); release-notes.mjs assert: OK; release job waits for approval

publish-floor.mjs then takes the direct arm, because a package that has never been published cannot be staged.

A test had to move with the version

test/package-contract.test.ts asserted manifest.version === '0.1.0'. That literal fails this commit and every later Version Packages pull request, since the release owns the version. The version is now held to the changelog the release writes: a plain x.y.z that CHANGELOG.md records as ## <version>, with 0.0.0 as the one unreleased value. The name, licence, module format and engine-floor assertions are unchanged, and no test of src/ behaviour is touched.

Also here

  • examples/: validate-parts.ts, render-at-precision.ts, instants-and-zones.ts, one per job the README describes. Each imports @cosyte/dates by name (resolved through the package's own exports after pnpm build), checks its output with node:assert/strict and exits non-zero on a mismatch. pnpm examples runs them through scripts/run-examples.ts, which also requires each one's final <name>: ok line and fails on an empty folder. CI runs it as a step of the single verify job, after the build. A planted wrong expectation turned the runner to exit 1.
  • Typecheck, lint, format cover examples/ and scripts/run-examples.ts. tsconfig.json maps @cosyte/dates to src/index.ts, because the release Verify ladder runs pnpm typecheck before pnpm build; the build output is byte-identical with the mapping.
  • eslint ignores .cosyte-release-tooling/. The Release run on Add the release pipeline: Changesets, the shared release caller and docs artifacts #6's merge failed in release / version because the shared workflow checks cosyte/.github out inside the working tree and eslint . linted those scripts (no-undef on URL, Buffer, console). Reproduced locally with the checkout in place: pnpm lint exit 1 before, 0 after. The full ladder (typecheck, lint, test, build, attw) passes in that order from a clean dist/ with the checkout present.
  • README: the status now states the promise the changeset makes (below 1.0.0 a breaking change ships in a minor version and is called out in the changelog; it used to say a major), points at examples/ and docs.cosyte.com/dates, and lists the CI gates.
  • package.json: homepage is https://docs.cosyte.com/dates, keywords add fhir, iso-8601, typescript. description, repository and bugs were already right.

The changeset

Its opening sentence is the release bullet: "First release of @cosyte/dates: validate, render and convert the date parts the @cosyte/* parsers return, without adding precision a value did not state or guessing a time zone." The body says what is dependable now, what the version number promises below 1.0.0, and what is not covered yet.

Checks run locally (pnpm 10.34.5)

  • On this commit: typecheck, lint, format:check, test (175 passed), test:tz, build, attw, examples, check:no-internal-refs, pack:docs, check-no-emdash.sh: all exit 0.
  • On the simulated Version Packages commit (0.1.0): the same ladder passes with .cosyte-release-tooling/ present.
  • README quickstart, from the simulated 0.1.0 build: pnpm build && npm pack (exit 0, cosyte-dates-0.1.0.tgz holding LICENSE, README.md, CHANGELOG.md, package.json and dist/), npm install ./cosyte-dates-0.1.0.tgz in an empty directory (exit 0), the block qs-extract.mjs extracts saved as quickstart.mts, node quickstart.mts: exit 0, printing the five lines the README shows.

https://claude.ai/code/session_01U24bnHKNxQWMxmfN7ny7w9

…data

Sets the manifest version to 0.0.0 and adds a minor changeset, so the
"Version Packages" pull request produces 0.1.0 through `changeset version`
and the first publish derives its release notes from that changeset.

Why 0.0.0: the shared release-notes gate derives notes only from a version
commit that moves package.json off a different version while deleting the
changesets it consumed. 0.1.0 is the only version this history has carried,
so the release workflow reads it as never-versioned and can never publish it,
and a changeset on top of 0.1.0 would ship 0.1.1 or 0.2.0. From 0.0.0 the
merge of this commit reads as version-reverted (is-release=false, the pull
request opens), and the Version Packages commit then moves 0.0.0 to 0.1.0
with this changeset consumed, which the gate accepts.

test/package-contract.test.ts pinned the version to the literal 0.1.0, which
would fail this commit and every later Version Packages pull request. The
version is now held to the changelog the release writes: a plain x.y.z that
CHANGELOG.md records as `## <version>`, with 0.0.0 as the one unreleased
value. The other identity assertions are unchanged.

Also in this commit:
- examples/: three programs, one per job the README describes, each importing
  @cosyte/dates by name, checking its own output and exiting non-zero on a
  mismatch; `pnpm examples` runs them via scripts/run-examples.ts, and CI runs
  it in the verify job after the build.
- tsconfig maps @cosyte/dates to src/index.ts so the examples typecheck
  before a build, as the release pipeline's Verify ladder runs typecheck
  first; the build output is byte-identical.
- README: the status now states the pre-1.0 promise the changeset makes,
  points at examples/ and docs.cosyte.com/dates, and lists the CI gates.
- package.json: homepage https://docs.cosyte.com/dates, wider keywords, tsx.
- eslint ignores `.cosyte-release-tooling/`: the shared release workflow
  checks cosyte/.github out inside the working tree before its Verify ladder
  runs `pnpm lint`, and `eslint .` linted those scripts, which failed the
  release run on main for the previous commit. Reproduced locally with the
  checkout in place, and green after the change.

Claude-Session: https://claude.ai/code/session_01U24bnHKNxQWMxmfN7ny7w9
@NSchatz
NSchatz merged commit 6ba2afd into main Sep 25, 2026
5 checks passed
@NSchatz
NSchatz deleted the release-0.1-prep branch September 25, 2026 20:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant