{
  "$type": "site.standard.document",
  "content": {
    "$type": "site.standard.content.markdown",
    "text": "import Callout from '../../components/mdx/Callout.astro'\n\nI really like [release-plz](https://release-plz.dev/) for my Rust projects ([balzac](https://balzac.rs) uses it); it's easy to configure, it automatically updates the relevant version fields (in cargo.toml) and can even update the `CHANGELOG.md` of your repo. There's only one problem: it only works with Rust. So I decided to make my own.\n\n## Better Releases\n\n[better releases](https://better-releases.com) is a tool that works on any Github repo, with any language and any stack. It uses a simple-ysh `brel.toml` file and:\n\n- reads the commit from the previous tag (if it exists)\n- figures out the next tag based on conventional commits\n- opens/updates a release pr\n\nOnce the pr is merged, it can optionally publish the detected tag to potentially trigger other workflows; in the [drizzle-sluggable](https://github.com/matfire/drizzle-sluggable) repo, this is what I use to trigger publishing the package to npm.\n\n## Getting Started\n\nTo get started, you need to install `brel` (better-releases' main tool); if you don't want to, you can also run it with\n\n```bash\nnpx brel@latest init\n```\n\nThe init command will ask some question to setup the base config and will generate the base workflow for Github Actions. Here's what the config file might look like\n\n```toml\ndefault_branch = \"main\"\n```\n\nBut we can do so much better than that.\n\n<Callout>\n  When modifying the config, you will need to rerun the init command to update\n  the workflow file\n</Callout>\n\n### Bumping Package versions\n\nHonestly, this feature is why I decided to build this tool: I wanted to be able to update versions across toml and json files (Rust, Javascript, PHP) with a single tool. Let's see how we can do this.\n\nFor a **package.json** file, we might want to bump the **version** field; with Brel, you can just do:\n\n```toml\n[release_pr.version_updates]\n\"package.json\" = [\"version\"]\n```\n\nBut that's not all! Imagine you want to update the version inside a lock file (though you probably shouldn't do this in CI), you can also pass selectors when selecting an array:\n\n```toml\n[release_pr.version_updates]\n\"Cargo.toml\" = [\"package.version\"]\n\"Cargo.lock\" = [\"package[name=brel].version\"]\n```\n\nYou might notice there's a **.lock** file in there; you can override the filetype like this:\n\n```toml\n[release_pr.format_overrides]\n\"Cargo.lock\" = \"toml\"\n```\n\n### Pushing a Tag\n\nLet's say we want to add automatic tag creation when merging the release branch; we can do so with a few config changes\n\n```toml\n[release_pr.tagging]\nenabled = true\ntag_template = \"{version}\"\n```\n\nWith this setup, merging the branch will create a tag corresponding to the version, like **0.7.0**\n\n<Callout type='warning'>\n  To actually enable release tagging, you need to provide a token allowed to do\n  so under the secret name BREL_TAG_PUSH_TOKEN\n</Callout>\n\n### Generating/Updating a Changelog\n\nWhen enabled, Brel integrates with [Git Cliff](https://git-cliff.org/) to automatically update a **CHANGELOG.MD** file. Here's how you might configure this:\n\n```toml\n[release_pr.changelog]\nenabled = true\noutput_file = \"CHANGELOG.md\"\n```\n\nThis will automatically update the **CHANGELOG.md** file using [Git Cliff](https://git-cliff.org)\n\n### There's more\n\nI will not bore you with everything Brel can do (you can even customize the template used for the pr body), but if you want to give it a try here's [the official website](https://better-releases.com) and the [github repo](https://github.com/better-releases/brel); do try it out if you have need of a tool like this and let me know what you think!",
    "version": "1.0"
  },
  "path": "/articles/better-releases-brel",
  "publishedAt": "2026-03-16T00:00:00.000Z",
  "site": "at://did:plc:dgtaz4vldacvqhvvmdvoc4ad/site.standard.publication/3mfbydibiwc7f",
  "tags": [
    "better-releases",
    "rust",
    "devops"
  ],
  "textContent": "import Callout from '../../components/mdx/Callout.astro'\n\nI really like release-plz for my Rust projects (balzac uses it); it's easy to configure, it automatically updates the relevant version fields (in cargo.toml) and can even update the  of your repo. There's only one problem: it only works with Rust. So I decided to make my own.\n\nBetter Releases\n\nbetter releases is a tool that works on any Github repo, with any language and any stack. It uses a simple-ysh  file and:\nreads the commit from the previous tag (if it exists)\nfigures out the next tag based on conventional commits\nopens/updates a release pr\n\nOnce the pr is merged, it can optionally publish the detected tag to potentially trigger other workflows; in the drizzle-sluggable repo, this is what I use to trigger publishing the package to npm.\n\nGetting Started\n\nTo get started, you need to install  (better-releases' main tool); if you don't want to, you can also run it with\n\nThe init command will ask some question to setup the base config and will generate the base workflow for Github Actions. Here's what the config file might look like\n\nBut we can do so much better than that.\n\n  When modifying the config, you will need to rerun the init command to update\n  the workflow file\n\nBumping Package versions\n\nHonestly, this feature is why I decided to build this tool: I wanted to be able to update versions across toml and json files (Rust, Javascript, PHP) with a single tool. Let's see how we can do this.\n\nFor a package.json file, we might want to bump the version field; with Brel, you can just do:\n\nBut that's not all! Imagine you want to update the version inside a lock file (though you probably shouldn't do this in CI), you can also pass selectors when selecting an array:\n\nYou might notice there's a .lock file in there; you can override the filetype like this:\n\nPushing a Tag\n\nLet's say we want to add automatic tag creation when merging the release branch; we can do so with a few config changes\n\nWith this setup, merging the branch will create a tag corresponding to the version, like 0.7.0\n\n  To actually enable release tagging, you need to provide a token allowed to do\n  so under the secret name BRELTAGPUSH_TOKEN\n\nGenerating/Updating a Changelog\n\nWhen enabled, Brel integrates with Git Cliff to automatically update a CHANGELOG.MD file. Here's how you might configure this:\n\nThis will automatically update the CHANGELOG.md file using Git Cliff\n\nThere's more\n\nI will not bore you with everything Brel can do (you can even customize the template used for the pr body), but if you want to give it a try here's the official website and the github repo; do try it out if you have need of a tool like this and let me know what you think!",
  "title": "Better Release PRs with brel",
  "updatedAt": "2026-05-17T13:09:08.248Z"
}