commit 221377f4fae9656f7b8852fef1f2a5a1871b9968
parent 487eb21385b09b10e737af4b94e855d4cc7cbfca
Author: Brennen Bearnes <code@p1k3.com>
Date: Mon, 28 Nov 2022 20:58:47 -0700
version to 2.6.0; rewrite docs for rolling release
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.
Diffstat:
5 files changed, 78 insertions(+), 87 deletions(-)
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,77 +1,62 @@
-# Contributing to Vimwiki
+# 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.
+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/ .
+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, 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.)
+If you want to provide a pull request on GitHub, start from the `dev` branch,
+not from the `master` branch.
+
+Version bureaucracy:
-Make sure to update `doc/vimwiki.txt` with the following information:
+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`
-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
+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.
-4. Add some non regression tests on:
- - The bug you fixed
- - The new feature you added
- - The API function you added or changed
-
-**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.
-- Also, when thinking about adding a new feature, it should be something which fits into the
- overall design of Vimwiki and which a significant portion of the users may like. Keep in mind
- that everybody has their own way to use Vimwiki.
-- Keep the coding style consistent.
-- Test your changes. Keep in mind that Vim has a ton of options and the users tons of different
- setups. Take a little time to think about under which circumstances your changes could break.
-
-## Git branching model
-
-- 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.
-
-## Preparing a release
-
-1. `git checkout dev`
-2. Update the changelog in the doc, nicely grouped, with a new version number and release date.
-3. Update the list of contributors.
-4. Update the version number at the top of the doc file.
-5. If necessary, update the Readme and the home page.
-6. `git checkout master && git merge dev`
-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.
-11. Tell the world.
-
-<!-- vim: set tw=99 : -->
+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/
diff --git a/autoload/vimwiki/tags.vim b/autoload/vimwiki/tags.vim
@@ -9,7 +9,8 @@
" Tags metadata in-file format:
"
-" Is based on CTags format (see |tags-file-format|).
+" Is based on CTags format (see |tags-file-format|) and
+" https://ctags.sourceforge.net/FORMAT
"
" {tagaddress} is set to lineno. We'll let vim search by exact line number; we
" can afford that, we assume metadata file is always updated before use.
@@ -291,8 +292,9 @@ function! s:write_tags_metadata(metadata) abort
endfor
endfor
call sort(tags, 's:tags_entry_cmp')
+ " TODO: VimWiki version probably shouldn't be hardcoded here:
let tag_comments = [
- \ "!_TAG_PROGRAM_VERSION\t2.5",
+ \ "!_TAG_PROGRAM_VERSION\t2.6.0",
\ "!_TAG_PROGRAM_URL\thttps://github.com/vimwiki/vimwiki",
\ "!_TAG_PROGRAM_NAME\tVimwiki Tags",
\ "!_TAG_PROGRAM_AUTHOR\tVimwiki",
diff --git a/doc/vimwiki.txt b/doc/vimwiki.txt
@@ -9,7 +9,7 @@
|___| |___| |_| |_||__| |__||___| |___| |_||___| ~
- Version: 2.5
+ Version: 2.6.0
==============================================================================
CONTENTS *vimwiki*
@@ -3995,7 +3995,14 @@ https://github.com/vimwiki/vimwiki/issues/, all others from
http://code.google.com/p/vimwiki/issues/list. They may be accessible from
https://github.com/vimwiki-backup/vimwiki/issues.
+From version 2.6.0, the VimWiki project has adopted a rolling release policy.
+Once changes are accepted, they will merge directly to dev, which is now the
+main branch. master is retained as a legacy mirror of the dev branch.
+
+2.6.0 (2022-11-28)~
+
New:~
+ * Policy: #1235: Move to semver and rolling release cadence
* Feature: #238: Reuse existing tabs with tab drop
* Issue #621: Feature request: Highlight code listings in HTML
* Issue #290: Calendar plugin, do not sign if no wiki
diff --git a/plugin/vimwiki.vim b/plugin/vimwiki.vim
@@ -10,8 +10,8 @@ if exists('g:loaded_vimwiki') || &compatible
endif
let g:loaded_vimwiki = 1
-" Set to version number for release, otherwise -1 for dev-branch
-let s:plugin_vers = 2.5
+" Set to version number for release:
+let s:plugin_vers = '2.6.0'
" Get the directory the script is installed in
let s:plugin_dir = expand('<sfile>:p:h:h')
@@ -209,21 +209,18 @@ endfunction
" Echo vimwiki version
" Called by :VimwikiShowVersion
function! s:get_version() abort
- if s:plugin_vers != -1
- echo 'Stable version: ' . string(s:plugin_vers)
+ echo 'Version: ' . s:plugin_vers
+ let l:plugin_rev = system('git --git-dir ' . s:plugin_dir . '/.git rev-parse --short HEAD')
+ let l:plugin_branch = system('git --git-dir ' . s:plugin_dir . '/.git rev-parse --abbrev-ref HEAD')
+ let l:plugin_date = system('git --git-dir ' . s:plugin_dir . '/.git show -s --format=%ci')
+ if v:shell_error == 0
+ echo 'Os: ' . vimwiki#u#os_name()
+ echo 'Vim: ' . v:version
+ echo 'Branch: ' . l:plugin_branch
+ echo 'Revision: ' . l:plugin_rev
+ echo 'Date: ' . l:plugin_date
else
- let l:plugin_rev = system('git --git-dir ' . s:plugin_dir . '/.git rev-parse --short HEAD')
- let l:plugin_branch = system('git --git-dir ' . s:plugin_dir . '/.git rev-parse --abbrev-ref HEAD')
- let l:plugin_date = system('git --git-dir ' . s:plugin_dir . '/.git show -s --format=%ci')
- if v:shell_error == 0
- echo 'Os: ' . vimwiki#u#os_name()
- echo 'Vim: ' . v:version
- echo 'Branch: ' . l:plugin_branch
- echo 'Revision: ' . l:plugin_rev
- echo 'Date: ' . l:plugin_date
- else
- echo 'Unknown version'
- endif
+ echo 'Unable to retrieve repository info'
endif
endfunction
diff --git a/test/tag.vader b/test/tag.vader
@@ -159,7 +159,7 @@ Expect (Correctly formatted tags file):
!_TAG_PROGRAM_AUTHOR Vimwiki
!_TAG_PROGRAM_NAME Vimwiki Tags
!_TAG_PROGRAM_URL https://github.com/vimwiki/vimwiki
- !_TAG_PROGRAM_VERSION 2.5
+ !_TAG_PROGRAM_VERSION 2.6.0
second-tag Test-Tag.md 13;" vimwiki:Test-Tag\tTest-Tag#second-tag\tTest-Tag#second-tag
test-tag Test-Tag.md 5;" vimwiki:Test-Tag\tTest-Tag#a-header\tA header
top-tag Test-Tag.md 1;" vimwiki:Test-Tag\tTest-Tag\tTest-Tag
