Release checklist
Copy MarkdownIncant is still experimental. Use this checklist before publishing a Hex release.
Package metadata
- Confirm package name and ownership on Hex.pm.
- Add package description, licenses, links, and maintainers in
mix.exs. - Confirm dependency constraints are appropriate for library consumers.
- Keep installer dependencies intentional; Igniter is runtime
falsebut available to the install task.
Versioning
- Set
versioninmix.exs. - Add or update a changelog before tagging.
- Avoid breaking DSL/API changes without a version bump.
Docs
- Keep
README.mdfocused on quick start and links. - Keep detailed guides under
docs/. - Verify examples compile or are clearly marked conceptual.
- Update
PLAN.md,CONVENTIONS.md, andREFERENCES.mdwhen product direction changes.
Current status
Verified before tagging a release:
mix cipasses.cd examples/playground && mix testpasses.- Playground
/adminrenders in a local Phoenix server. - API naming remains
actor,actor_assign,actor, andpolicyfor now.
Tests
Run:
mix test
cd examples/playground && mix test
Before release, also run the full project CI alias when dependencies/tools are available:
mix ci
Playground
- Confirm
/adminrenders. - Confirm Catalog, LLM, and Support examples still make sense.
- Avoid public demo routes that look like product API unless documented.
Installer
- Test
mix incant.installin a fresh Phoenix app. - Verify starter files are generated.
- Verify router patch is correct.
- Verify Tailwind CSS source patch is correct.
- Verify fallback instructions are useful when files are missing.
Authorization
- Confirm default behavior remains allow-all without a policy.
- Confirm
actor_assignandactorcallback extraction work. - Confirm policy scoping protects list and detail data.
- Confirm local resource/dashboard policies override the admin policy where intended.
Publishing
mix hex.build
mix hex.publish
Tag the release after publishing:
git tag vX.Y.Z
git push origin vX.Y.Z