1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
# Contributing to VimWiki
# Filing a bug
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/
# Git branching model
As of v2022.12.02, VimWiki has adopted a rolling release model, along with
[calendar versioning][calver]. A release should be
[prepared][#preparing-a-release] for every change or set of changes which merge
to `dev`.
[calver]: https://calver.org/
There are two permanent branches:
1. `dev`: This is the default branch, and where changes are released. Tasks
which are done in one or only a few commits go here directly. Always
keep this branch in a working state. If the task you work on requires
multiple commits, make sure intermediate commits don't make VimWiki
unusable.
2. `master`: This is a legacy branch, retained to avoid breaking existing
checkouts of the plugin. It should be kept in sync with `dev`.
Large changes which require multiple commits may be authored in feature
branches, and merged into `dev` when the work is done.
# Creating a pull request
If you want to provide a pull request on GitHub, start from the `dev` branch,
not from the `master` branch.
Version bureaucracy:
1. Pick a new version number according to the current date:
`YYYY.MM.DD` (if releasing a second version for the
current date, append a `_MICRO` version such as `_1`, `_2`, etc.
- Examples: `2022.12.22`, `2022.12.22_1`
2. Update the version number at the top of `plugin/vimwiki.vim`
3. Update the `!_TAG_PROGRAM_VERSION` expected in `test/tag.vader`
(this is a bit silly, will have to figure out how to get rid of it)
Update `doc/vimwiki.txt` with the following information:
1. Update the changelog to include, at the top of it, information on the new
feature the PR introduces or the bug it is fixing as well as the PR number
and related issue number if possible.
2. Add a help section to describe any new features or options.
3. If you are a first time contributor add your name to the list of
contributors.
# Preparing a release
This section is primarily for maintainers.
1. Set a tag with the version number in Git: `git tag -a v2022.12.02 -m 'Release v2022.12.02'`
2. `git push --tags`
3. 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.
4. If necessary, update `README.md` and the home page.
5. For major changes: Tell the world.
[semver]: https://semver.org/
|
