nsxiv157cda5
Document development workflow for maintainers (#202)
+36 −0
1 file changed
- M CONTRIBUTING.md +36 −0
| @@ -21,6 +21,8 @@ When contributing, make sure: | |||
| 21 | 21 | * Your contribution falls under nsxiv's scope and aim | |
| 22 | 22 | * You follow the existing code style (see [.editorconfig](.editorconfig)) | |
| 23 | 23 | * You open the pull request from a new branch, not from master | |
| 24 | + | * To avoid using force pushes, especially for bigger patches. Only use them | |
| 25 | + | when there's merge conflicts. | |
| 24 | 26 | ||
| 25 | 27 | If your contribution is not suitable for general use, it will not be included in nsxiv. | |
| 26 | 28 | For changes that are very much up to preference, such as changing values in config.h, | |
| @@ -36,3 +38,37 @@ to work on. You can also filter the issues via label: | |||
| 36 | 38 | Might require some experience. | |
| 37 | 39 | * [Help wanted](https://github.com/nsxiv/nsxiv/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22): | |
| 38 | 40 | (Intermediate/Experienced) Issues where we require some help. | |
| 41 | + | ||
| 42 | + | Development workflow for maintainers | |
| 43 | + | ------------------------------------ | |
| 44 | + | ||
| 45 | + | If we notice you contributing and/or showing interest in issues/pull requests, | |
| 46 | + | we may invite you to join the nsxiv org as a member. Being a member simply means | |
| 47 | + | you will be able to approve, disapprove and merge pull requests. | |
| 48 | + | ||
| 49 | + | Our workflow regarding pull requests is the following: | |
| 50 | + | ||
| 51 | + | * Code related changes require two approvals, but documentation related | |
| 52 | + | changes (e.g. typo) can be merged with just one. | |
| 53 | + | * Always prefer squashing when merging. In the case a PR makes more than one | |
| 54 | + | significant change, use the "don't squash" tag and rebase instead. | |
| 55 | + | * When merging, make sure the commit message is cleaned up properly so that | |
| 56 | + | it reflects the current intention of the PR. | |
| 57 | + | ||
| 58 | + | For releases, the process is the following: | |
| 59 | + | ||
| 60 | + | * Tag the release with a "vN" tag, where N is the version number. Also set | |
| 61 | + | the commit message and tag description for the release commit to "Release | |
| 62 | + | version N". | |
| 63 | + | * Update `VERSION` macro in the `Makefile`. | |
| 64 | + | * Update the changelog (`CHANGELOG.md`): | |
| 65 | + | * Include link to the release tarball and add the release date. | |
| 66 | + | * Document only the changes or fixes between releases. Don't document | |
| 67 | + | changes which never made it into a release. | |
| 68 | + | * Use the "Changes" section to document behavior changes since the last | |
| 69 | + | release, the "Added" section for new features, and the "Fixes" section | |
| 70 | + | for fixed bugs or regressions. Include pull request IDs. | |
| 71 | + | ||
| 72 | + | For mundane development related talks which don't warrant their own issue, use | |
| 73 | + | the [general-dev](https://github.com/nsxiv/nsxiv/discussions/119) discussion | |
| 74 | + | thread. | |