Releasing a major version of a go library must require manual intervention beyond approving a PR. Major versions contain breaking changes to the public API of modules and needs to be carefully managed and avoided if possible.
The current behaviour does not align with Go's module versioning scheme. We have had a few instances of changes unintentionally bumping the major version of a library.
https://github.com/coopnorge/go-services-interfaces/pull/131 is an example of this, the PR was labeled with release-drafter-go:major and caused a v1.0.0 release to be generated, that release was later published. For context the ignore-major-changes-for-pattern was misconfigured and did not ignore the breaking change, however these accidents should not happen, it would have been better to have CI fail.
This is a rough outline to the expected behaviour:
Go lang breaking change detected -> fail CI
New major version package structure detected vN directory at root level -> label with major version
Break glass feature for when we want to do a change that is detected as breaking: manually add an override label, -> label with minor versio
Releasing a major version of a go library must require manual intervention beyond approving a PR. Major versions contain breaking changes to the public API of modules and needs to be carefully managed and avoided if possible.
The current behaviour does not align with Go's module versioning scheme. We have had a few instances of changes unintentionally bumping the major version of a library.
https://github.com/coopnorge/go-services-interfaces/pull/131 is an example of this, the PR was labeled with
release-drafter-go:majorand caused av1.0.0release to be generated, that release was later published. For context theignore-major-changes-for-patternwas misconfigured and did not ignore the breaking change, however these accidents should not happen, it would have been better to have CI fail.This is a rough outline to the expected behaviour:
vNdirectory at root level -> label with major versionRef: