genbumppush

[compare changes](https://github.com/xcvzmoon/genbumppush/compare/v0.0.7...v0.0.8)

### 🚀 Enhancements

- docker: Support multiple images per release ([197dd43](https://github.com/xcvzmoon/genbumppush/commit/197dd43))

### 📖 Documentation

- docker: Document multi-image publication and api+web example ([a326b47](https://github.com/xcvzmoon/genbumppush/commit/a326b47))

### ✅ Tests

- docker: Cover multi-image plan, publish, and dry-run ([33a3986](https://github.com/xcvzmoon/genbumppush/commit/33a3986))

### ❤️ Contributors

- Mon Albert Gamil ([@xcvzmoon](https://github.com/xcvzmoon))

Releasing software is one of those tasks that looks trivial from a distance and still manages to punish you up close. Bump a version. Update a few files. Write a changelog. Commit. Tag. Push. Hope the tag workflows fire. Hope the package manager accepts the release. Hope nothing got half-written when the network blipped. Do this across a Node library, a web app, a monorepo, and a Tauri project, and the “simple” checklist becomes a ritual you re-invent every time and still get wrong sometimes.

I built genbumppush because I was tired of that ritual living in my head, in a half-finished shell script, or in a heavy release framework that wanted to own my entire CI pipeline. The name is the product thesis in three words: generate the changelog, bump the version, push the release. Everything else follows from that.

This covers handling package.json in a monorepo, github or gitlab release, docker tags, and many interesting features