v0.13.2

null

#
# Write a message for release:
#   v0.13.2
#
# - The first line is the release title.
# - Subsequent lines are the release notes.
# - This comment will be stripped from the release notes

v0.13.1

Bug Fixes

• fcbb1d3 remove contributor empty lines in default template

v0.13.0 — The Simpsons Release

A release to improve contribution tracking, with special guests.

---

Features

• 11bc91d Support contributor footers in changelog generation

Contributions

This release is made possible by the following people (in alphabetical order).
Thank you all for your contributions. Your work – no matter how significant – is
greatly appreciated by the community. 💖

• Bart Simpson ([email protected])

• Homer Simpson ([email protected])

• Lisa Simpson ([email protected])

• Marge Simpson ([email protected])

v0.12.0 — A promise made is a promise kept.

It took the better part of five years to keep this promise, but here we
are.

---

Features

• e9b2784 Add support for ignoring specific commits
• 1d01661 Add root commit filtering for changelog generation

v0.11.0

This release allows release notes without subjects. If a tag message
contains multiple lines without a newline between the first and second
line, the entire message will be used as part of the release note,
instead of treating the first line as the release title.

---

Bug Fixes

• 7f7854f Improve git tag message parsing for subject extraction

v0.10.0

Bug Fixes

• f0274d6 handle empty release notes
• e08fb2c write to stdout by default, as intended
• c3ae8ed resolve newline formatting in default template

Features

• b0dcc8a --strip-config excludes metadata from rendered changelog

0.9.0 — Back to our roots!

In the last few days, I dug Jilu in a hole that kept getting deeper. It
started with the question “how can I fit Jilu in the release flow I
want”, and ended with “now, how do I make Jilu create signed annotated
tags?”

Jilu is not a release management tool. It is a change log generator.
Jilu needs access to Git, yes, but it should never need write access
to the repository. All it needs is a list of commits, and a list of
existing tags, nothing else. In fact, we could just have Jilu itself
never interact with Git and feed it the commits and tags data through
external means, but that would tip the scales in the other direction:
making Jilu too minimalist for its own good.

Instead, the right balance is this:

• Jilu is a change log generator
• It needs read access to a Git repository
• It will never change any Git objects
• It will only write to the change log file, if requested
• It can be used as a cog in a larger release workflow

This last item is what drove me down this rabbit hole, but here we are,
back at the surface, this release officially seals the hole, and puts us
on a much saner path.

So how can we still achieve that last item, without having write access
to Git? Well, we push data instead of pull, meaning, when you run
jilu, you can now ask it for structured (JSON) output with all the
relevant change log data you could need, to feed into your release
workflow.

This is done through the new --output flag, which can be either
text, json, or none. If you call jilu --write, then --output
is set to none, If you call it as jilu then output is set to text,
unless you explicitly set it to none. This is how things worked
implicitly until this release. Now, there’s a new json option, which
gives you structured data of the generated change log:

jilu --output=json

{
  "config": {
    "github": {
      "repo": "rustic-games/jilu"
    },
    "accept_types": [...],
    "type_headers": {
      "refactor": "Refactoring",
      ...
    }
  },
  "unreleased": {
    "changes": [],
  },
  "releases": [
    {
      "version": "0.8.0",
      "subject": "Commit or don't, there is no such thing as a free lunch.",
      "notes": "Swap `--tag` for `--commit`, bringing us closer to a proper release\nworkflow.",
      "date": "2025-06-09T14:47:02Z",
      "changeset": {
        "changes": [
          {
            "type": "feat",
            "scope": "changelog",
            "description": "Add commit functionality to release workflow",
            "body": "...",
            "commit": {
              "short_id": "83e7793",
              "id": "83e7793ab13dcf9739f0d76684ef0e9c08b98ee4"
            }
          }
        ],
        "contributors": [
          {
            "name": "Jean Mertz",
            "email": "[email protected]"
          }
        ]
      }
    },
    ...
  ]
}

As you can see, there’s a lot of data you can use in external tools. One
obvious use-case is creating a release commit and tag, which is what we
introduced in 0.8.0, and are now removing again.

You can use a tool like jq to query this data in a script you
maintain, or you can use the new --jq flag to have Jilu do the JSON
filtering, without needing to install jq. This is mostly a convenience
feature for those that don’t have Jq installed.

Here’s how you can create the relevant release commit and tag in a shell
script:

# Create a temporary file to store the change log JSON output. This is
# required, because using `--edit` requires stdout to be a TTY for our
# editor, so we need to write the JSON output to a file instead of
# stdout.
release=$(mktemp)

# 1. We group the unreleased changes in a new release 0.9.0
# 2. We edit the release notes in our $EDITOR
# 3. We write the changes to our CHANGELOG.md
# 4. We return the change log data as JSON to stdout
# 5. We filter the JSON to the latest release (0.9.0)
# 6. We write the JSON output to our temporary file
jilu --release=v0.9.0 \
     --edit \
     --write \
     --output=json \
     --jq='.releases[0]' \
     --output-file="$release"

# 1. We make sure to stage the change log changes
git add CHANGELOG.md

# 1. We use `jq -r` to produce a raw (unquoted) string for us
# 2. We create a new release commit message
# 3. We commit the staged changes
msg=$(echo "$release" | jq -r '"chore: Release v" + .version')
git commit --message "$msg"

# 1. We create a new release tag message
# 2. We create the tag
msg=$(echo "$release" | jq -r '[.subject, .notes] | join("\n\n")')
git tag --sign --message "$msg"

This is one example, but it shows how you can use the structured data
any way you want in your release pipeline, without Jilu becoming a
bloated complicated tool that does too many things poorly, instead of a
dedicated tool that does a few things extremely well.

---

• e52d264 feat: Add JSON output with JQ filtering support
• 391a952 fix: properly render release headings on Github

Commit or don't, there is no such thing as a free lunch.

Swap --tag for --commit, bringing us closer to a proper release
workflow.

Tag, you're it!

Tag your releases, plain and simple.

The Goodies Release

A list of changes that make using Jilu a little easier.

• Configure Jilu using CLI arguments (see jilu --help).
• sponge no longer needed, let Jilu write the release notes to a file.
• Group unreleased commits into a release before a tag is created.
• Skip thanking specific contributors in the default template using
  IGNORE_CONTRIBUTORS.
• Support HTML comments in change log templates.