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.