Brennen Bearnes
221377f4fa
This: - Changes version number everywhere I could find it. - Reworks get_version() to dispense with stable / dev division. - Rewrites CONTRIBUTING.md to describe a new release workflow. The development/release workflow stuff could use some thought. It's clunky at best. There's sort of an inherent tension between semver-style version numbers and the rolling release thing - maybe we should just use commit hash or something date-based? Still, it's a start.
63 lines
2.4 KiB
Markdown
63 lines
2.4 KiB
Markdown
# 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 v2.6.0, VimWiki has adopted a rolling release model, while (for the
|
|
moment) retaining specific version numbers. A release should be
|
|
[prepared][#preparing-a-release] for every change or set of changes which merge
|
|
to `dev`.
|
|
|
|
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 [semver][semver] rules:
|
|
`git tag vMAJOR.MINOR.PATCH`
|
|
2. Update the version number at the top of `doc/vimwiki.txt`
|
|
3. Update the version number at the top of `plugin/vimwiki.vim`
|
|
4. Update the version number in `autoload/vimwiki/tags.vim`
|
|
|
|
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
|
|
|
|
1. Set a tag with the version number in Git.
|
|
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/
|