chore(deps): update dependency knope to v0.22.2

[renovate]

This PR contains the following updates:

Package	Update	Change
knope (source)	minor	0.10.0 → 0.22.2

---

Release Notes

knope-dev/knope (knope)

v0.22.2

Features

Add [changes] config section with ignore_conventional_commits setting

Adds a new top-level [changes] configuration section to control how Knope processes changes. The first setting in this section is ignore_conventional_commits, which when set to true, makes Knope ignore conventional commits and only use changesets for determining version bumps and changelog entries.

This replaces the deprecated step-level ignore_conventional_commits option on the PrepareRelease step. Use knope --upgrade to automatically migrate from the old format to the new one.

Example configuration:

[changes]
ignore_conventional_commits = true

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

See the changes config documentation for more details.

Fixes

• add help text to release and document-change workflows

v0.22.1

Features

• Add support for multiple regex patterns when versioning a single file

Fixes

Fix $version variable used after --override-version

Previously, if you used BumpVersion or PrepareRelease with --override-version and then used a $version variable with
a Command, the variable would still be set to the original version (pre-bump).

Thanks @​andrewmcgivery for the report!

v0.22.0

Breaking Changes

Knope now specifies the current local commit when creating releases on GitHub or Gitea

Previously, releases were created at the head of the default branch.

v0.21.7

Fixes

Require at least one package to be selected to create a change file

Fixes #​1686. Thanks for the report @​t-moe!

v0.21.6

Fixes

• #​1678 cant have a prerelease label with a 'v' in it. (#​1680)

v0.21.5

Features

Add support for updating version numbers in arbitrary text files using regex patterns. You can now specify versioned files with a regex field containing a named capture group called version:

[package]
versioned_files = [
    "Cargo.toml",
    { path = "README.md", regex = 'version:\s+(?<version>\d+\.?\d+\.?\d+)' }
]

This allows Knope to automatically update version numbers in documentation, installation instructions, and other text files that don't have a structured format.

v0.21.4

Features

Add first-class Deno release support to Knope

##​1577 by @​jeckhart

• Detect Deno projects, workspaces, and nested packages so they can be released with Knope
• Reuse the deno_config and deno_lockfile crates to stay current with maintained Deno config and lockfile formats
• Extend release pipeline so Deno projects get version bumps and changelogs consistent with Node.js projects
• Updated Concept docs for Change, Changeset, Package
• Updated Reference docs for Packages and Default Config
• Add tests for deno based projects and workspaces

v0.21.3

Fixes

Fix pre-release versioning when there are no previous stable versions

Previously, if there was not a Git tag containing a previous stable version, Knope would default to "0.0.0".
Because of the special 1.0.0 rules, this also meant there was no way to start a project at a pre-release of 1.0.0
with no prior releases.

Now, if there are no previous stable releases, Knope will use the version in your files instead of calculating a version
based on "0.0.0".

Fixes #​1515, thanks for the report @​hazre!

v0.21.2

Features

• Support workspace.package.version in Cargo.toml

v0.21.1

Features

Add support for customizing release note entries

You can now customize individual entries in release notes to change the formatting or add authors/hashes to entries when available.

v0.21.0

Breaking Changes

Change to default handling of top-level package.json files

When using the default config (no [package] or [packages]), Knope will now treat a top-level package.json file
which contains a workspaces property as the entrypoint into a monorepo and not a single versioned_file package.

Support package-lock.json files

package-lock.json files are now supported
as versioned_files both for single packages and dependencies (in monorepos).

These files will be auto-detected and updated if using the default (no [package] or [packages]) config, so
this is a breaking change for those users.

Features

Add support for dependencies in package.json files

You can now update the dependencies and devDependencies of a package.json like this:

[package]
versioned_files = [
  # Update @​my/package-name in dependencies and devDependencies whenever this package version updates
  { path = "package.json", dependency = "@​my/package-name" }
]

Support for NPM workspaces

Knope now supports NPM-style workspaces when using the default config!

Fixes

Fix multiple versioned files with same path

Previously, if you referenced the same file multiple times in versioned_files, only the first instance would apply.
Now, if you reference the same path multiple times, each instance will be processed sequentially.

Consider a mono-repo where every package should be versioned in lockstep:

[package]
versioned_files = [
  "package.json",
  { path = "package.json", dependency = "aDependency" },  # Before this fix, this was ignored
  "aDependency/package.json"
]

This use-case is now supported!

v0.20.0

Breaking Changes

Add default variables

Default variables will now apply anywhere they can be
used—including the Command and CreatePullRequest steps.

If any of the defaults, like $version or $changelog, appear in a variable-supporting location
and you don't have explicit variables = set for that step, this is a breaking change.

Fixes

Fix detecting previous releases with no changelog

Previously, if you ran a PrepareRelease step with no changelog to modify in one workflow and then a Release step
in a separate workflow, Release would fail to create a Git tag.

Now, a release with "no notes" will properly be created if the last Git tag doesn't match the current version of
a file.
If a forge is configured, a release will be created on that forge without any notes,
and a title simply containing the version.

Fixes #​1267

PrepareRelease will allow empty releases when using --override-version

Fixes #​1423

v0.19.2

Features

• Print each step before it runs when --verbose is set (#​1399)

v0.19.0

Breaking Changes

Updated config locations

Knope is internally using a newer crate for storing persistent config, so some things (like GitHub tokens) may need to
be updated on next run.

Documentation

Document creating releases with Knope Bot

Knope Bot can make creating releases easier than ever now!

v0.18.5

Features

Add versioning support for gleam.toml files

##​1352 by @​dbanty

Closes #​1350

v0.18.4

Features

Add basic support for versioning of pom.xml files

pom.xml must contain a <version> field in the <project> section.
Dependencies and multi-module projects are not yet supported.

Fixes

Don't normalize existing changeset file names

When a new change file is created via CreateChangeFile,
its name is generated by converting the summary of the change to all lowercase letters and underscores.
This same normalization was happening when opening an existing change file, which prevented that change file from
being deleted during a PrepareRelease step if it didn't match the normalized version
(for example, was created with a different tool or by hand).
This has been fixed.

Fixes #​1340

Notes

• Update to Rust edition 2024 and MSRV 1.85

v0.18.3

Fixes

• Improve error messages when GitHub releases fail

v0.18.2

Fixes

• Fix panic when Cargo.toml is missing a version
• Remove warning for Cargo.lock version 4

v0.18.1

Features

Support glob patterns for package assets

You can now provide a glob pattern when defining package assets instead of specifying each file individually in a list.
This is especially useful when your asset names are dynamic (containing a version, date, or hash, for example) or
when different releases have different assets.

Knope will not error if the glob pattern doesn't match any files.
You can't combine glob patterns with individual file names.

[package]
assets = "assets/*"

v0.18.0

Breaking Changes

Auto-update Cargo workspace dependencies when using default config

If using the Cargo workspace default configuration,
Knope will now attempt to automatically update the version of workspace members in dependencies and the workspace Cargo.lock.

To avoid this, use knope --generate to create a manual config file and customize the behavior.

Don't create any go module tags that match package names

Knope already avoided creating duplicate tags for Go modules which match tags that would be created by the Release step for the package.
Now, Knope won't create a Go module tag if it matches a release tag for any configured package, to avoid potential conflicts.

Features

Support for Cargo.lock in versioned_files

Dependencies within a Cargo.lock can now be updated.

Support for dependencies within Cargo.toml

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

Fixes

Deduplicate release actions

Knope now collects all actions to be performed across all packages and runs them at once with deduplication.

This means that if multiple packages write to the same versioned_file, for example, the file will only be written
a single time.
Changesets will also only be deleted once, files will be staged to Git only once, etc.

This mostly only impacts the output during --dry-run or --verbose, but is especially important for the new
dependency updating and lockfile support.

v0.17.0

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 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.

v0.16.2

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.

v0.16.1

Compare Source

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!

v0.16.0

Compare Source

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

v0.15.0

Compare Source

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!

v0.14.1

Compare Source

Features

Add ignore_go_major_versioning option

You can now set ignore_go_major_versioning = true for a package in
knope.toml to turn off the major version validation & updating in go.mod files.

More details in the new docs.

Closes #​863, thanks for the suggestion @​BatmanAoD!

v0.14.0

Compare Source

Breaking Changes

Cargo.toml files must now have a package.name property

This was already required by Cargo, but wasn't enforced by Knope until now. Before, a Cargo.toml file like

[package]
version = "0.1.0"

was acceptable, but now it must be

[package]
name = "my-package"
version = "0.1.0"

Features

Add basic Cargo workspace support

If you have a Cargo.toml file in the working directory which represents a Cargo workspace containing fixed members, like:

[workspace]
members = [
  "my-package",
  "my-other-package",
]

then Knope will now treat each member like a package.
There must be a Cargo.toml file in each member directory, or Knope will error.

This doesn't work with path globbing yet, only manual directory entries. See the new docs for more details.

Use default packages/workflows even when knope.toml exists

If you define a knope.toml file without any packages, Knope will assume the default packages (as if you had no knope.toml file at all).

Likewise, if you have no [[workflows]] in a knope.toml file, Knope will assume the default workflows.

Fixes

Homebrew tap now contains Apple Silicon binaries and auto-publishes new versions (#​827)

v0.13.4

Compare Source

Features

Gitea support

PR #​759 closed issue #​743. Thank you, @​FallenValkyrie!

• Added Support for Gitea in the CreatePullRequest step
• Added Support for Gitea in the Release step
• Added A new SelectGiteaIssue step
• Add support to generate Gitea config from known public Gitea instances

To use these new steps, just add a new section to your configuration, like this:

[gitea]
repo = "knope"
owner = "knope-dev"
host = "https://codeberg.org"

You can now use the supported steps in the same way as their GitHub equivalents.

[!TIP]
Knope can now generate a configuration for you, if your repository's remote is one of the known
public Gitea instances. Currently only Codeberg is supported,
but feel free to add more here.

v0.13.3

Compare Source

Features

Support pubspec.yaml in versioned_files

Knope can now version Dart projects! You can now add a pubspec.yaml file to your package.versioned_files.

PR #​732 closes #​731. Thanks @​FallenValkyrie!

v0.13.2

Compare Source

Fixes

Add [github] section with knope --generate (#​666)

--dry-run will no longer report deleting the same changeset twice (#​668)

CreateChangeFile (like knope document-change) now prints package names. (#​669)

v0.13.1

Compare Source

Documentation

There is a new docs website

Check out https://knope.tech/ to see the new docs, and please report any errors or gaps!
All error messages within Knope should be updated to point to the new docs.
If any are still pointed at GitHub pages (as of this version), that's a bug!

As part of this, you can also now install Knope through Chocolatey and Homebrew!

v0.13.0

Compare Source

Breaking Changes

Change changeset title level

The level of the title of a changeset no longer impacts the level of the release header in the changelog. To make this more obvious, changeset title are now level one headers by default. This is a breaking change because older versions of Knope will no longer properly handle the changesets from newer versions of Knope.

Change where new versions are inserted in changelog

In practice, this will not impact most changelogs, however, previous versions of Knope looked for the first header at a certain level (e.g., starting with ## ) and inserted the new version right before that. Now, Knope looks for the first header that is parseable as a semver version (e.g., ## 1.2.3) and inserts the new version right before that.

This will make it harder to adopt Knope in projects that have an existing changelog which is not of the same format,
but it makes inserting the new version in the changelog more robust.

Features

Allow overriding built-in changelog sections

If you don't want to use the default changelog sections of "Breaking changes", "Features",
and "Fixes", you can now override them by using the equivalent changeset types!
Overriding them resets their position in the changelog, so you probably want to reset all of them if you reset any.
This looks like:

[package]
extra_changelog_sections = [
    { type = "major", name = "❗️Breaking ❗" },
    { type = "minor", name = "🚀 Features" },
    { type = "patch", name = "🐛 Fixes" },
    { footer = "Changelog-Note", name = "📝 Notes" },
]

Support level-one release headers in changelogs

If the last release in a changelog file has a level-one header instead of Knope's default of level-two, new releases will be created with level-one headers as well. Sections will then be level two instead of level three.

v0.12.0

Compare Source

Breaking Changes

Prevent bumping major version of a go.mod file

According to the docs, aside from the v0 -> v1 transition, go.mod files should not be updated for new major versions, but instead a new v{major} directory should be created with a new go.mod file. This is for compatibility with older versions of Go tools.

In order to prevent someone from accidentally doing the wrong thing, Knope will no longer bump a go.mod file to v2 unless --override-version is used to bypass this check. Additionally, if a go.mod file is in the matching versioned directory (e.g., the go.mod file ending in /v2 is under a directory called v2), Knope will not allow the major version of that file to be bumped, as it would break the package.

Fixes

Handle version-specific go modules correctly

Fixes #​584 from @​BatmanAoD.

If you have a go.mod file representing a specific major version in a directory (as recommended in the go docs), Knope will now tag it correctly. Previously, a v2/go.mod file would generate a tag like v2/v2.1.3. Now, it will generate a tag like v2.1.3.

Additionally, when determining the current version for a go.mod file, only tags which match the major version of the go.mod file will be considered.

Properly version named packages containing a root go.mod file

Consider this package config in a knope.toml:

[packages.something]
versioned_files = ["go.mod"]

The Release step previously (and will still) add a tag like something/v1.2.3, however the correct Go module tag is v1.2.3 (without the package name prefix). Knope will now correctly add this second tag (previously, top-level tags were only added for single-package repos).

Documentation

Document conflict between package names and go module names

It is possible to write a knope.toml file which will cause conflicting tags during the Release step if you have go.mod files in nested directories. This is now documented.

v0.11.1

Compare Source

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!

v0.11.0

Compare Source

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.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.