0.11.1 (2023-09-22)

Features

Add a ChangelogEntry variable for substitution

Anywhere that the existing Version variable can be used (for example, in the Command step), you can now also use ChangelogEntry to get the section of the changelog that corresponds to the current version. For example, you could (almost) replicate Knope's GitHub Release creation without Knope's GitHub integration with a workflow like this:

[[workflows]]
name = "release"

[[workflows.steps]]
type = "PrepareRelease"

[[workflows.steps]]
type = "Command"
command = "git commit -m \"chore: prepare release $version\" && git push"

[workflows.steps.variables]
"$version" = "Version"

[[workflows.steps]]
type = "Command"
command = "gh release create --title '$version' --notes '$changelog'"

[workflows.steps.variables]
"$version" = "Version"
"$changelog" = "ChangelogEntry"

Added an allow_empty option to the PrepareRelease step

Closes #416

If you want to run PrepareRelease on every push to a branch without it failing when there's nothing to release, you can now include the allow_empty option like this:

[[workflows.steps]]
type = "PrepareRelease"
allow_empty = true

Then, you can use some logic to gracefully skip the rest of your CI process if there is nothing to release. For example, in GitHub Actions, you could do something like this:

- name: Prepare Release
  run: knope prepare-release
- name: Check for Release
  id: status
  run: echo ready=$(if [[ `git status --porcelain` ]]; then echo "true"; else echo "false"; fi;) >> $GITHUB_OUTPUT
- name: Release
  if: steps.status.outputs.ready == 'true'
  run: knope release

This allows you to differentiate between there being nothing to release and the PrepareRelease step failing for other reasons.

New CreatePullRequest step

The new CreatePullRequest step allows you to create or update a pull request on GitHub. It's designed to be a nice way to preview and accept new releases via a pull request workflow, but could certainly work for more contexts as well! To see an example of the new PR-based release workflow, check out Knope's prepare-release workflow and Knope's release workflow.

Fixes

Only consider prereleases newer than the last stable

This fixes a regression in the previous version of Knope where all prereleases would be considered, rather than just those tagged after the latest stable version.

Documentation

GitHub Actions Recipes

There's a new section of the docs with some recipes for using Knope in GitHub Actions. If you have suggestions for additional recipes, please open a discussion!

0.11.0 (2023-09-13)

Breaking Changes

Ignore unreachable tags when determining version

PR #574 fixes issue #505 from @BatmanAoD.

Previously, the latests tags were always used to determine the current version, even if those tags were not reachable from HEAD. Now, only reachable tags will be considered. Use the --verbose flag to see tags which are being ignored.

Fixes

Consistent commit selection in branching histories

PR #574 fixes issue #505 from @BatmanAoD.

Previous versions of Knope did not handle branching histories correctly. In some cases, this could result in commits from previous stable releases being included in a new release. It could also result in missing some commits that should have been included. This has been fixed—Knope should provide you the same commit list that git rev-list {previous_stable_tag}..HEAD would.

0.10.0 (2023-09-09)

Breaking Changes

Reworked Go versioning

In order to support running Release in a separate workflow from PrepareRelease and to fix a bug relating to Go module tags (when in a subdirectory), Knope will now store the full package version in a comment in the go.mod file and use that version as the source of truth for the package version. This has a couple of implications:

1. If you already have a comment on the module line in go.mod which matches the correct format, Knope may not be able to determine the version correctly.
2. If you have a comment on that line which does not match the format, it will be erased the next time Knope bumps the version.

In either case, the solution is to erase or move that comment. Here is the syntax that Knope is looking for:

module {ModulePath} // v{Version}

If that comment does not exist, Knope will revert to looking for the latest relevant Git tag instead to determine the version, but will still write the comment to the go.mod file when bumping the version.

Features

--verbose flag

PR #545 closed issue #534 by @BatmanAoD.

There is now a global --verbose flag that will spit out lots of extra info to stdout to assist with debugging. Right now, only the process for determining and bumping new package versions is instrumented, open issues if you need more info!

Allow Release step to be in separate workflow than PrepareRelease

Previously, you needed to have a PrepareRelease step earlier in the same workflow if you wanted to use the Release step. Now, if you run a Release step without a PrepareRelease step, Knope will check Git tags and versioned files to figure out if there's something new to release. This is especially useful if you want to build release assets using the new version (determined by PrepareRelease) before actually releasing them (using Release).

Upload assets to GitHub Releases

You can now add assets to a package like this:

[package]
versioned_files = ["Cargo.toml"]
changelog = "CHANGELOG.md"

[[package.assets]]
path = "artifact/knope-x86_64-unknown-linux-musl.tgz"
name = "knope-x86_64-unknown-linux-musl.tgz"  # Optional, defaults to file name (so this `name` is doing nothing)

[[package.assets]]
path = "artifact/knope-x86_64-pc-windows-msvc.tgz"

When running the Release step with a valid [github] config, instead of immediately creating the release, Knope will:

1. Create a draft release
2. Upload all listed assets (erroring if any don't exist)
3. Publish the release

Fixes

Use the correct tags for go.mod files in subdirectories

PR #544 fixed issue #502 by @BatmanAoD.

Previously, the version for a go.mod file was determined by the package tag, named v{Version} for single packages or {PackageName}/v{Version} for named packages. This worked when the go.mod file was in the root of the repository or a directory named {PackageName} (respectively), but not when it was in a different directory. Now, the version tag, both for determining the current version and creating a new release, will correctly be determined by the name of the directory the go.mod file is in (relative to the working directory). The existing package tagging strategy remains unchanged.

For example, consider this knope.toml file:

[package]
versioned_files = ["some_dir/go.mod"]

Previous to this release, creating the version 1.2.3 would only create a tag v1.2.3. Now, it will additionally create the tag some_dir/v1.2.3.

0.9.0 (2023-08-10)

Breaking Changes

Removed the deprecated [[packages]] syntax

If you're using the old syntax, run knope --upgrade before switching to this version.

--generate can no longer be used if a knope.toml file already exists

Workflows can no longer be selected interactively

Previously, it was valid to invoke knope with no arguments, and the user would be prompted interactively to select a workflow. Now, a workflow must be provided as a positional argument, for example, knope release.

The --prerelease-label option can only be provided after a workflow

Previously, the --prerelease-label CLI option was always available globally and would simply be ignored if it was not useful for the selected workflow. Now, it can only be provided after the name of a workflow which can use the option (right now, only a workflow which contains a PrepareRelease step). For example, with the default workflow, knope release --prerelease-label="rc" is valid, but none of these are valid:

• knope --prerelease-label="rc" release
• knope document-change --prerelease-label="rc"

--upgrade can no longer be used if there is no knope.toml file

--validate can no longer be used if there is no knope.toml file

Features

Added the --override-version option to manually set the next version

Allows you to manually determine the next version for a [BumpVersion] or [PrepareRelease] instead of using a semantic versioning rule. This option can only be provided after a workflow which contains a relevant step. This has two formats, depending on whether there is one package or multiple packages:

1. --override-version 1.0.0 will set the version to 1.0.0 if there is only one package configured (error if multiple packages are configured).
2. --override-version first-package=1.0.0 --override-version second-package=2.0.0 will set the version of first-package to 1.0.0 and second-package to 2.0.0 if there are multiple packages configured (error if only one package is configured).

This closes #497.

knope --help now lists all available workflows

0.8.0 (2023-06-19)

Breaking Changes

Changelog entries now use 4th level headers instead of bullets

In order to support more detailed changelogs via changesets (like the extra text you're seeing right now!) instead of each change entry being a single bullet under the appropriate category (e.g., ### Breaking Changes above), it will be a fourth-level header (####). So, where this changelog entry would have currently looked like this:

## Breaking Changes

- Changelog entries now use 4th level headers instead of bullets

It now looks like what you're seeing:

## Breaking Changes

### Changelog entries now use 4th level headers instead of bullets

... recursion omitted

If a change note starts with #### already (like in changesets), it will be left alone.

Features

Move GitHub Release headers up a level (#467, #472)

Added dates to version titles

There are now release dates in both changelogs and version names on GitHub. This probably won't break your releases, but you will have a different format for release notes which could be jarring. The date is in the format YYYY-MM-DD and will always be based on UTC time (so if you do a release late at night on the east coast of the United States, the date will be the next day).

Previously, the changelog entry title would look like this:

# 1.0.0

And now it will look like this:

# 1.0.0 (2023-06-10)

Report files to be added to git in --dry-run

The PrepareRelease adds modified files to Git. Now, when running with the --dry-run option, it will report which files would be added to Git (for easier debugging).

Note: The default knope release workflow includes this [PrepareRelease] step.

Remove duplicate version from GitHub release name

Release notes in GitHub releases used to copy the entire section of the changelog, including the version number. Because the name of the release also includes the version, you'd see the version twice, like:

# 1.0.0

# 1.0.0

... notes here

Now, that second ## 1.0.0 is omitted from the body of the release.

Added support for changesets

Leveraging the new changesets crate, Knope now supports changesets! In short, you can run knope document-change (if using default workflows) or add the new [CreateChangeFile] step to a workflow to generate a new Markdown file in the .changeset directory. You can then fill in any additional details below the generated header in the generated Markdown file. The next time the PrepareRelease step runs (e.g., in the default knope release workflow), all change files will be consumed to help generate a new version and changelog (along with any conventional commits).

For additional details, see:

• PrepareRelease step
• CreateChangeFile step
• Packages (for how you can customize changelog sections)

0.7.4

0.7.4

Features

• Allow more changelog sections via extra_changelog_sections config or the default Changelog-Note commit footer. (#450)

0.7.3

0.7.3

Features

• Remove any potential panics (#429)

Fixes

• Handle merge commits in history. Thanks @erichulburd! (#443)

0.7.2

0.7.2

Fixes

• Avoid GLIBC issues by skipping gnu builds (#407)

0.7.1

Fixes

• Fix building from source / cargo install by upgrading to gix. (#383)

0.7.0

0.7.0

Breaking Changes

• Handling of pre-release versions has been reworked to handle many more edge cases, which results in more correct (but different) behavior.

Fixes

• Check all relevant pre-release versions, not just the latest [#334, #346]. Thanks @Shadow53!