From 68e33e37e51a53dbee916d1756b8fef2c2ecfdf5 Mon Sep 17 00:00:00 2001 From: Rane Brown Date: Fri, 20 Dec 2019 20:40:59 -0700 Subject: [PATCH] Add info about testing with vader and vint. Stylistic fixes. --- CONTRIBUTING.md | 50 +++++++++++++++++++++++++------------------------ 1 file changed, 26 insertions(+), 24 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1685084..c6eb9f4 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,11 +1,6 @@ -# Filing a bug +# Contributing to Vimwiki -Before filing a bug or starting to write a patch, check the latest development version from -https://github.com/vimwiki/vimwiki/tree/dev to see if your problem is already fixed. - -Issues can be filed at https://github.com/vimwiki/vimwiki/issues/ . - -# Creating a pull request +## Pull Requests If you want to provide a pull request on GitHub, please start from the `dev` branch, not from the `master` branch. (Caution, GitHub shows `master` as the default branch from which to start a PR.) @@ -15,9 +10,16 @@ Make sure to update `doc/vimwiki.txt` with the following information: 1. Update the changelog to include information on the new feature the PR introduces or the bug it is fixing. 2. Add a help section to describe any new features or options. -2. If you are a first time contributor add your name to the list of contributors. +3. If you are a first time contributor add your name to the list of contributors. -# More info and advice for (aspiring) core developers +**Testing:** Vimwiki uses [vader](https://github.com/junegunn/vader.vim) for unit tests and +[vint](https://github.com/Kuniwak/vint) for linting. Any new PRs must add new tests and pass all +linter checks. See the [test README](test/README.md) for more info. + +- In addition to the included tests, there are more example wikis that can be used for testing + [here](https://github.com/vimwiki/testwikis). + +## More info and advice for (aspiring) core developers - Before implementing a non-trivial feature, think twice what it means for the user. We should always try to keep backward compatibility. If you are not sure, discuss it on GitHub. @@ -30,17 +32,17 @@ Make sure to update `doc/vimwiki.txt` with the following information: ## Git branching model -- there are two branches with eternal lifetime: - - `dev`: This is where the main development happens. Tasks which are done in one or only a few - commits go here directly. Always try to keep this branch in a working state, that is, if the - task you work on requires multiple commits, make sure intermediate commits don't make Vimwiki - unusable (or at least push these commits at one go). - - `master`: This branch is for released states only. Whenever a reasonable set of changes has - piled up in the `dev` branch, a [release is done](#Preparing a release). After a release, - `dev` has been merged into `master` and `master` got exactly one additional commit in which - the version number in `plugin/vimwiki.vim` is updated. Apart from these commits and the merge - commit from `dev`, nothing happens on `master`. Never should `master` merge into `dev`. When - the users ask, we should recommend this branch for them to use. +- There are two branches with eternal lifetime: + 1. `dev`: This is where the main development happens. Tasks which are done in one or only a few + commits go here directly. Always try to keep this branch in a working state, that is, if the + task you work on requires multiple commits, make sure intermediate commits don't make + Vimwiki unusable (or at least push these commits at one go). + 2. `master`: This branch is for released states only. Whenever a reasonable set of changes has + piled up in the `dev` branch, a [release is done](#preparing-a-release). After a release, + `dev` has been merged into `master` and `master` got exactly one additional commit in which + the version number in `plugin/vimwiki.vim` is updated. Apart from these commits and the + merge commit from `dev`, nothing happens on `master`. Never should `master` merge into + `dev`. When the users ask, we should recommend this branch for them to use. - Larger changes which require multiple commits are done in feature branches. They are based on `dev` and merge into `dev` when the work is done. @@ -55,9 +57,9 @@ Make sure to update `doc/vimwiki.txt` with the following information: 7. Update the version number at the top of plugin/vimwiki.vim. 8. Set a tag with the version number in Git: `git tag vX.Y` 9. `git push --tags` -10. In GitHub, go to _Releases_ -> _Draft a new release_ -> choose the tag, convert the changelog from the - doc to markdown and post it there. Make plans to build an automatic converter and immediately - forget this plan. +10. In GitHub, go to _Releases_ -> _Draft a new release_ -> choose the tag, convert the changelog + from the doc to markdown and post it there. Make plans to build an automatic converter and + immediately forget this plan. 11. Tell the world. -%% vim:tw=99 +