- Signed and verified CLA
- Golang 1.13.x
- (To run linter) https://github.com/golangci/golangci-lint in
$PATH
> go run mage.go -v lint
> go run mage.go -v test
> go run mage.go -v bench
> go run mage.go -v benchandgraph
-
Check existing issues and verify that your issue is not already submitted. If it is, it's highly recommended to add to that issue with your reports.
-
Open issue
-
Be as detailed as possible -
go
version, what did you do, what did you expect to happen, what actually happened.
- Find an existing issue to work on or follow
Submitting an issue
to create one that you're also going to fix. Make sure to notify that you're working on a fix for the issue you picked. - Branch out from latest
master
. - Code, add, commit and push your changes in your branch.
- Make sure that tests and linter(s) pass locally for you.
- Submit a PR.
- Collaborate with the codeowners/reviewers to merge this in
master
.
- Releases are only created from tags.
- Tags are based on
master
. master
is meant to be stable, so before tagging a new release, make sure that the CI checks pass formaster
.- Releases and tags are following semantic versioning.
- Releases are GitHub releases.
- Releases and tags are to be named in pattern of
vX.Y.Z
. The produced binary artifacts contain thevX.Y.Z
in their names. This is due how GitHub's CDNs work. They must be unique regardless if it's a different release. - Changelog must up-to-date with what's going to be released. Check CHANGELOG.
- Push a new Git tag in pattern of
vX.Y.Z
. - Wait for GitHub action for
release
to workflow to kick in at https://github.com/sumup-oss/gocat/actions . - If all is good, a new GitHub release will be created and assets will be uploaded there.