config 0.1.0 (2024-08-18)

Breaking Changes

Support for dependencies within Cargo.toml

Dependencies within a Cargo.toml file can now be updated
as part of versioned_files.

versioning 0.2.0 (2024-08-10)

Breaking Changes

• Move HeaderLevel to internal, parse with Changelog::new

versioning 0.1.0 (2024-08-04)

Breaking Changes

Everything has changed

And hopefully it won't break anyone since this crate isn't ready for external consumers yet!

Features

• Add handling of changes (conventional commits, changesets)

knope 0.17.0 (2024-08-04)

Breaking Changes

Forge date now matches CHANGELOG date

If you prepare a release and generate a changelog Markdown file in one workflow, then create a forge (GitHub or Gitea) release in a separate workflow, the forge release date will now match the changelog date (if any). Previously, the forge release got the current date (at the time of running the workflow).

Match scope-filtering behavior to docs

The docs state, in regard to a package.scopes config, "if not defined, Knope will consider all scopes."

This is the intended behavior, but wasn't true until now. The actual behavior, for multi-package repos, was that if
any package had scopes defined, all would start filtering scopes.

This has been corrected, packages are now more independent in their scope filtering behavior.

Properly use case insensitivity when checking conventional commits

Per the conventional commits spec all units of a
conventional commit are case-insensitive.
Until now, Knope was treating commit footers and scopes as case-sensitive. This has been corrected, which may result
in different behavior for some projects.

config 0.0.1 (2024-08-04)

Features

• Initial release

versioning 0.0.1 (2024-04-14)

Features

• Initial release

knope 0.16.2 (2024-04-14)

Features

Add get-version default workflow

For single-package repositories with no custom workflows defined,
there is now a default workflow called get-version that
prints out the current package version.

If you want similar functionality for multi-package repositories, please add your ideas to issue #988.

Thanks to @BatmanAoD for the suggestion and @alex-way for the implementation!

PR #994 closed #885.

Add option to ignore conventional commits

You can now add ignore_conventional_commits = true to a PrepareRelease step
to ignore commit messages (and only consider changesets):

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

PR #1008 closes #924. Thanks for the suggestion @ematipico!

Fixes

• Allow omitting the variables field for CreatePullRequest title and body

Documentation

Created a new recipe for converting a single-package repo into a monorepo

Knope itself is now a monorepo—the process of converting it was documented here.

0.16.1 (2024-03-24)

Features

Add help_text option to workflows

[[workflows]] can now have help_text:

Example:

[[workflows]]
name = "release"
help_text = "Prepare a release"

The message is displayed when running knope --help:

A command line tool for automating common development tasks

Usage: knope [OPTIONS] [COMMAND]

Commands:
release          Prepare a release
help             Print this message or the help of the given subcommand(s)

...

PR #960 closes issue #959. Thanks @alex-way!

Use bullets to describe simple changes

The previous changelog & forge release format used headers for the summary of all changes, these entries were hard
to follow for simple changes like this:

## Features

### A feature

### Another header with no content in between?

Now, simple changes are described with bullets at the top of the section. More complex changes will come after
any bullets, using the previous format:

## Features

- A simple feature
- Another simple feature

### A complex feature

Some details about that feature

Right now, a simple change is any change which comes from a conventional commit (whether from the commit summary or
from a footer) or a changeset with only a header in it. Here are three simple changes:

feat: A simple feature

Changelog-Note: A note entry

---
default: minor
---

# A simple feature with no description

A complex change is any changeset which has content (not just empty lines) below the header.

PR #969 implemented #930. Thanks for the suggestion @ematipico!

0.16.0 (2024-03-20)

Breaking Changes

Don't delete changesets for prereleases

Previously, using PrepareRelease to create a prerelease (for example, with --prerelease-label) would delete all
changesets, just like a full release. This was a bug, but the fix is a breaking change if you were
relying on that behavior.

Features

Add a shell variable for Command steps

You can now add shell=true to a Command step to run the command in the current shell.
This lets you opt in to the pre-0.15.0 behavior.

[[workflows.steps]]
type = "Command"
command = "echo $AN_ENV_VAR"
shell = true

0.15.0 (2024-03-18)

Breaking Changes

Don't run Command steps in shell

The Command step no longer attempts to run the command in a default shell for the detected operating system.
This fixes a compatibility issue with Windows.

If this change doesn't work for your workflow, please open an issue describing your need so we can fix it.

Notably, using && in a command (as was the case for some default workflows) will no longer work. Instead, split this
into multiple Command steps.

PR #919 closes issue #918. Thanks for reporting @alex-way!