bij1
/
gogreen
19
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

update CONTRIBUTING

This commit is contained in:
Hilary Holz 2020-03-30 18:52:00 -07:00
parent fe3b2c825b
commit 60ef1725ce
1 changed files with 18 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
CONTRIBUTING.md
View File

@ -1,25 +1,17 @@
# Contributing
If you submit a pull request, please keep the following guidelines in mind:
We love contributions! You are welcome to open a pull request, but it's a good idea to
open an issue and discuss your idea with us first.
Once you are ready to open a PR, please keep the following guidelines in mind:
1. Code should be `go fmt` compliant.
2. Types, structs and funcs should be documented.
3. Tests pass.
1. Types, structs and funcs should be documented.
1. Tests pass.
## Getting set up
Assuming your `$GOPATH` is set up according to your desires, run:
```sh
go get github.com/digitalocean/godo
go get -u github.com/stretchr/testify/assert
```
If outside `$GOPATH`, just clone the repository:
```sh
git clone https://github.com/digitalocean/godo
```
`godo` uses go modules. Just fork this repo, clone your fork and off you go!
## Running tests
@ -31,13 +23,21 @@ go test -mod=vendor .
## Versioning
Godo follows [semver](https://www.semver.org) versioning semantics. New functionality should be accompanied by increment to the minor version number. The current strategy is to release often. Any code which is complete, tested, reviewed, and merged to master is worthy of release.
Godo follows [semver](https://www.semver.org) versioning semantics.
New functionality should be accompanied by increment to the minor
version number. Any code merged to master is subject to release.
## Releasing
Releasing a new version of godo is currently a manual process.
Releasing a new version of godo is currently a manual process.
1. Update the `CHANGELOG.md` with your changes. If a version header for the next (unreleased) version does not exist, create one. Include one bullet point for each piece of new functionality in the release, including the pull request ID, description, and author(s).
Submit a separate pull request for the version change from the pull
request with your changes.
1. Update the `CHANGELOG.md` with your changes. If a version header
for the next (unreleased) version does not exist, create one.
Include one bullet point for each piece of new functionality in the
release, including the pull request ID, description, and author(s).
```
## [v1.8.0] - 2019-03-13