Skip to content

Commit 621b891

Browse files
committed
chore: prepare release 0.10.0
1 parent 0104fec commit 621b891

7 files changed

+70
-77
lines changed

.changeset/_verbose_flag.md

-9
This file was deleted.

.changeset/allow_release_step_to_be_in_separate_workflow_as_preparerelease.md

-7
This file was deleted.

.changeset/reworked_go_versioning.md

-16
This file was deleted.

.changeset/upload_assets_to_github_releases.md

-26
This file was deleted.

.changeset/use_the_correct_tags_for_gomod_files_in_subdirectories.md

-18
This file was deleted.

CHANGELOG.md

+69
Original file line numberDiff line numberDiff line change
@@ -4,6 +4,75 @@ All notable changes to this project will be documented in this file.
44

55
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
66

7+
## 0.10.0 (2023-09-09)
8+
9+
### Breaking Changes
10+
11+
#### Reworked Go versioning
12+
13+
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:
14+
15+
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.
16+
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.
17+
18+
In either case, the solution is to erase or move that comment. Here is the syntax that Knope is looking for:
19+
20+
`module {ModulePath} // v{Version}`
21+
22+
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.
23+
24+
### Features
25+
26+
#### `--verbose` flag
27+
28+
PR #545 closed issue #534 by @BatmanAoD.
29+
30+
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!
31+
32+
#### Allow `Release` step to be in separate workflow than `PrepareRelease`
33+
34+
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`).
35+
36+
#### Upload assets to GitHub Releases
37+
38+
You can now add assets to a package like this:
39+
40+
```toml
41+
[package]
42+
versioned_files = ["Cargo.toml"]
43+
changelog = "CHANGELOG.md"
44+
45+
[[package.assets]]
46+
path = "artifact/knope-x86_64-unknown-linux-musl.tgz"
47+
name = "knope-x86_64-unknown-linux-musl.tgz" # Optional, defaults to file name (so this `name` is doing nothing)
48+
49+
[[package.assets]]
50+
path = "artifact/knope-x86_64-pc-windows-msvc.tgz"
51+
```
52+
53+
When running the `Release` step with a valid `[github]` config, instead of immediately creating the release, Knope will:
54+
55+
1. Create a draft release
56+
2. Upload all listed assets (erroring if any don't exist)
57+
3. Publish the release
58+
59+
### Fixes
60+
61+
#### Use the correct tags for `go.mod` files in subdirectories
62+
63+
PR #544 fixed issue #502 by @BatmanAoD.
64+
65+
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.
66+
67+
For example, consider this `knope.toml` file:
68+
69+
```toml
70+
[package]
71+
versioned_files = ["some_dir/go.mod"]
72+
```
73+
74+
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`.
75+
776
## 0.9.0 (2023-08-10)
877

978
### Breaking Changes

Cargo.toml

+1-1
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
[package]
22
name = "knope"
33
description = "A command line tool for automating common development tasks"
4-
version = "0.9.0"
4+
version = "0.10.0"
55
authors = ["Dylan Anthony <[email protected]>"]
66
edition = "2021"
77
license = "MIT"

0 commit comments

Comments
 (0)