y0rune/vimwiki
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Add info about testing with vader and vint.

Browse Source 
Stylistic fixes.
This commit is contained in:
Rane Brown 2019-12-20 20:40:59 -07:00
parent 7c892e2516
commit 68e33e37e5
1 changed files with 26 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
CONTRIBUTING.md
View File

@ -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 ## Pull Requests
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
If you want to provide a pull request on GitHub, please start from the `dev` branch, not from the 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.) `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 1. Update the changelog to include information on the new feature the PR introduces or the bug it
is fixing. is fixing.
2. Add a help section to describe any new features or options. 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 - 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. 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 ## Git branching model
- there are two branches with eternal lifetime: - 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 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 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 task you work on requires multiple commits, make sure intermediate commits don't make
unusable (or at least push these commits at one go). 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 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, 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 `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 the version number in `plugin/vimwiki.vim` is updated. Apart from these commits and the
commit from `dev`, nothing happens on `master`. Never should `master` merge into `dev`. When merge commit from `dev`, nothing happens on `master`. Never should `master` merge into
the users ask, we should recommend this branch for them to use. `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 - 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. `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. 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` 8. Set a tag with the version number in Git: `git tag vX.Y`
9. `git push --tags` 9. `git push --tags`
10. In GitHub, go to _Releases_ -> _Draft a new release_ -> choose the tag, convert the changelog from the 10. In GitHub, go to _Releases_ -> _Draft a new release_ -> choose the tag, convert the changelog
doc to markdown and post it there. Make plans to build an automatic converter and immediately from the doc to markdown and post it there. Make plans to build an automatic converter and
forget this plan. immediately forget this plan.
11. Tell the world. 11. Tell the world.
%% vim:tw=99 <!-- vim:tw=99 -->