# `mix publish_check`

Verifies that a pending release is internally consistent.

```sh
mix publish_check [TAG] [--notes-file PATH]
```

With a `TAG` (the release workflow passes the pushed tag), checks that:

- `TAG` (with an optional leading `v`) matches the `mix.exs` version.
- `CHANGELOG.md` has a dated `## vX.Y.Z` section for that version, and the section is
  not empty.

Without a `TAG`, the latest planned release is taken from the changelog (the first `##
vX.Y.Z` heading) and checked against the `mix.exs` version. If they differ, the release
is not ready: bump `@version` in `mix.exs` before tagging.

Every version heading in the changelog must have both the version and the target release
date (`## vX.Y.Z / YYYY-MM-DD`). The date must be a valid ISO 8601 date at most 7 days
in the future.

Any `##` heading that does not start with a version (`## NEXT`, `## Unreleased`, ...) is
a placeholder for a release whose version is not yet decided. A changelog containing
one, or a version heading without a valid date, is not ready to release (with or without
a `TAG`).

## Options

- `--notes-file PATH` - write the changelog section for the release to `PATH`
  (suitable for `gh release create --notes-file`).

---

*Consult [api-reference.md](api-reference.md) for complete listing*