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.
2.4 KiB
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:
- Pick a new version number according to semver rules:
git tag vMAJOR.MINOR.PATCH - Update the version number at the top of
doc/vimwiki.txt - Update the version number at the top of
plugin/vimwiki.vim - Update the version number in
autoload/vimwiki/tags.vim
Update doc/vimwiki.txt with the following information:
- 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.
- Add a help section to describe any new features or options.
- If you are a first time contributor add your name to the list of contributors.
Preparing a release
- Set a tag with the version number in Git.
git push --tags- 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.
- If necessary, update
README.mdand the home page. - For major changes: Tell the world.