CHANGELOG.md lists [1.0.0] as not yet published, while package.json is already at 1.0.0 and the repo tagline says v1.0.0-era API. Whenever the first real release happens, this will be confusing: the version will already have existed in package.json for months.
What to do (whichever release strategy is chosen)
- Either date the
[1.0.0] CHANGELOG entry and tag v1.0.0 at the commit that gets published, or
- restart the public history at
0.x to match the "Early stage / experimental" status (pairs with the stability discussion) and rename the CHANGELOG section accordingly.
- Add the release procedure (version bump, tag, CHANGELOG date, npm publish) to
CONTRIBUTING.md or docs/ so the next release doesn't drift the same way.
Acceptance criteria
package.json version, CHANGELOG headings, and git tags tell one consistent story at first publish.
CHANGELOG.mdlists[1.0.0]as not yet published, whilepackage.jsonis already at1.0.0and the repo tagline says v1.0.0-era API. Whenever the first real release happens, this will be confusing: the version will already have existed inpackage.jsonfor months.What to do (whichever release strategy is chosen)
[1.0.0]CHANGELOG entry and tagv1.0.0at the commit that gets published, or0.xto match the "Early stage / experimental" status (pairs with the stability discussion) and rename the CHANGELOG section accordingly.CONTRIBUTING.mdordocs/so the next release doesn't drift the same way.Acceptance criteria
package.jsonversion, CHANGELOG headings, and git tags tell one consistent story at first publish.