Releases: knope-dev/knope
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 = true0.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.
Contributors
Assets 6
0.14.1 (2024-02-23)
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!
Contributors
Assets 6
0.14.0 (2024-02-04)
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)
0.13.4 (2024-01-13)
Features
Gitea support
PR #759 closed issue #743. Thank you, @FallenValkyrie!
- Added Support for Gitea in the
CreatePullRequeststep - Added Support for Gitea in the
Releasestep - Added A new
SelectGiteaIssuestep - 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.
0.13.3 (2023-12-17)
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!
0.13.2 (2023-11-11)
0.13.1 (2023-11-05)
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!
0.13.0 (2023-10-22)
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.
0.12.0 (2023-09-30)
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.