github.com/Datadog/cnab-go@v0.3.3-beta1.0.20191007143216-bba4b7e723d0/CONTRIBUTING.md (about) 1 We have [good first issues][good-first-issue] for new contributors and [help wanted][help-wanted] issues for our other contributors. 2 3 * `good first issue` has extra information to help you make your first contribution. 4 * `help wanted` are issues suitable for someone who isn't a core maintainer. 5 6 Maintainers will do our best regularly make new issues for you to solve and then help out as you work on them. 💖 7 8 # Philosophy 9 PRs are most welcome! 10 11 * If there isn't an issue for your PR, please make an issue first and explain the problem or motivation for 12 the change you are proposing. When the solution isn't straightforward, for example "Implement missing command X", 13 then also outline your proposed solution. Your PR will go smoother if the solution is agreed upon before you've 14 spent a lot of time implementing it. 15 * It's OK to submit a PR directly for problems such as misspellings or other things where the motivation/problem is 16 unambiguous. 17 * If you aren't sure about your solution yet, put WIP in the title or open as a draft PR so that people know to be nice and 18 wait for you to finish before commenting. 19 * Try to keep your PRs to a single task. Please don't tackle multiple things in a single PR if possible. Otherwise, grouping related changes into commits will help us out a bunch when reviewing! 20 * We encourage "follow-on PRs". If the core of your changes are good, and it won't hurt to do more of 21 the changes later, we like to merge early, and keep working on it in another PR so that others can build 22 on top of your work. 23 24 When you're ready to get started, we recommend the following workflow: 25 26 ``` 27 $ go build ./... 28 $ go test ./... 29 $ golangci-lint run --config ./golangci.yml 30 ``` 31 32 We currently use [dep](https://github.com/golang/dep) for dependency management. 33 34 [good-first-issue]: https://github.com/deislabs/cnab-go/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 35 [help-wanted]: https://github.com/deislabs/cnab-go/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22 36 37 # Cutting a Release 38 39 When you are asked to cut a new release, here is the process: 40 41 1. Figure out the correct version number, we follow [semver](semver.org) and 42 have a funny [release naming scheme][release-name]: 43 * Bump the major segment if there are any breaking changes. 44 * Bump the minor segment if there are new features only. 45 * Bump the patch segment if there are bug fixes only. 46 * Bump the build segment (version-prerelease.BUILDTAG+releasename) if you only 47 fixed something in the build, but the final binaries are the same. 48 1. Figure out if the release name (version-prerelease.buildtag+RELEASENAME) should 49 change. 50 51 * Keep the release name the same if it is just a build tag or patch bump. 52 * It is a new release name for major and minor bumps. 53 54 If you need a new release name, it must be conversation with the team. 55 [Release naming scheme][release-name] explains the meaning behind the 56 release names. 57 1. Ensure that the master CI build is passing, then make the tag and push it. 58 59 ``` 60 git checkout master 61 git pull 62 git tag VERSION -a -m "" 63 git push --tags 64 ``` 65 66 1. Generate some release notes and put them into the release on GitHub. 67 The following command gives you a list of all the merged pull requests: 68 69 ``` 70 git log --oneline OLDVERSION..NEWVERSION | grep "#" > gitlog.txt 71 ``` 72 73 You need to go through that and make a bulleted list of features 74 and fixes with the PR titles and links to the PR. If you come up with an 75 easier way of doing this, please submit a PR to update these instructions. 😅 76 77 ``` 78 # Features 79 * PR TITLE (#PR NUMBER) 80 81 # Fixes 82 * PR TITLE (#PR NUMBER)