Document development workflow for maintainers (#202)
Co-authored-by: NRK <nrk@disroot.org> Co-authored-by: Berke Kocaoğlu <berke.kocaoglu@metu.edu.tr>
This commit is contained in:
parent
a9c6cbcd20
commit
157cda5b31
@ -21,6 +21,8 @@ When contributing, make sure:
|
|||||||
* Your contribution falls under nsxiv's scope and aim
|
* Your contribution falls under nsxiv's scope and aim
|
||||||
* You follow the existing code style (see [.editorconfig](.editorconfig))
|
* You follow the existing code style (see [.editorconfig](.editorconfig))
|
||||||
* You open the pull request from a new branch, not from master
|
* You open the pull request from a new branch, not from master
|
||||||
|
* To avoid using force pushes, especially for bigger patches. Only use them
|
||||||
|
when there's merge conflicts.
|
||||||
|
|
||||||
If your contribution is not suitable for general use, it will not be included in nsxiv.
|
If your contribution is not suitable for general use, it will not be included in nsxiv.
|
||||||
For changes that are very much up to preference, such as changing values in config.h,
|
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:
|
|||||||
Might require some experience.
|
Might require some experience.
|
||||||
* [Help wanted](https://github.com/nsxiv/nsxiv/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22):
|
* [Help wanted](https://github.com/nsxiv/nsxiv/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22):
|
||||||
(Intermediate/Experienced) Issues where we require some help.
|
(Intermediate/Experienced) Issues where we require some help.
|
||||||
|
|
||||||
|
Development workflow for maintainers
|
||||||
|
------------------------------------
|
||||||
|
|
||||||
|
If we notice you contributing and/or showing interest in issues/pull requests,
|
||||||
|
we may invite you to join the nsxiv org as a member. Being a member simply means
|
||||||
|
you will be able to approve, disapprove and merge pull requests.
|
||||||
|
|
||||||
|
Our workflow regarding pull requests is the following:
|
||||||
|
|
||||||
|
* Code related changes require two approvals, but documentation related
|
||||||
|
changes (e.g. typo) can be merged with just one.
|
||||||
|
* Always prefer squashing when merging. In the case a PR makes more than one
|
||||||
|
significant change, use the "don't squash" tag and rebase instead.
|
||||||
|
* When merging, make sure the commit message is cleaned up properly so that
|
||||||
|
it reflects the current intention of the PR.
|
||||||
|
|
||||||
|
For releases, the process is the following:
|
||||||
|
|
||||||
|
* Tag the release with a "vN" tag, where N is the version number. Also set
|
||||||
|
the commit message and tag description for the release commit to "Release
|
||||||
|
version N".
|
||||||
|
* Update `VERSION` macro in the `Makefile`.
|
||||||
|
* Update the changelog (`CHANGELOG.md`):
|
||||||
|
* Include link to the release tarball and add the release date.
|
||||||
|
* Document only the changes or fixes between releases. Don't document
|
||||||
|
changes which never made it into a release.
|
||||||
|
* Use the "Changes" section to document behavior changes since the last
|
||||||
|
release, the "Added" section for new features, and the "Fixes" section
|
||||||
|
for fixed bugs or regressions. Include pull request IDs.
|
||||||
|
|
||||||
|
For mundane development related talks which don't warrant their own issue, use
|
||||||
|
the [general-dev](https://github.com/nsxiv/nsxiv/discussions/119) discussion
|
||||||
|
thread.
|
||||||
|
Loading…
Reference in New Issue
Block a user