Releases: knope-dev/knope
versioning 0.3.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
.
Features
Support for Cargo.lock
in versioned_files
Dependencies within a Cargo.lock
can now be updated.
knope 0.18.0 (2024-08-18)
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.
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!
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 forCreatePullRequest
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!