Releasing Onion

Onion uses git tags to drive releases. The version is derived automatically from the latest tag by sbt-dynver, so there is no manual version := ... line to update in build.sbt.

Release checklist

1. Make sure develop is green.

   sbt test
   

2. Decide the next version. Onion follows Semantic Versioning with milestone and RC pre-releases when needed:

3. Patch release: v0.2.1
4. Minor release: v0.3.0
5. Milestone: v0.3.0-M1

6. Release candidate: v0.3.0-RC1

7. Update CHANGELOG.md. Add a new section for the release with the date and a summary of user-facing changes, bug fixes, and internal improvements.

8. Create and push a tag.

   git checkout develop
   git pull
   git tag -a v0.2.0 -m "Release v0.2.0"
   git push origin v0.2.0
   

9. Let CI do the rest. The release workflow will:

10. run the test suite,
11. build the fat jar (sbt assembly) and the distribution zip (sbt dist),
12. verify the tag matches the sbt-derived version,
13. smoke-test the fat jar,
14. generate SHA-256 checksums,

15. create a GitHub Release with the artifacts and auto-generated notes.

16. Verify the release.

17. Check the GitHub Release page.
18. Download onion-<version>.jar and confirm:

    java -cp onion-<version>.jar onion.tools.ScriptRunner run/Hello.on
    

Local artifact inspection

To build the same artifacts locally without creating a release:

sbt assembly dist

Outputs: - target/scala-3.3.7/onion-<version>.jar (fat jar) - target/onion-dist-<version>.zip (distribution archive)

Hotfix releases

For a hotfix against an already-released version, branch from the release tag, apply the fix, and push a new patch tag (e.g. v0.2.1).