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.

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
+Before filing a bug or starting to write a patch, check the latest development
-https://github.com/vimwiki/vimwiki/tree/dev to see if your problem is already fixed.
+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
+If you want to provide a pull request on GitHub, start from the `dev` branch,
-`master` branch. (Caution, GitHub shows `master` as the default branch from which to start a PR.)
+not from the `master` branch.
 
-Make sure to update `doc/vimwiki.txt` with the following information:
+Version bureaucracy:
 
-1. Update the changelog to include, at the top of it, information on the new feature
+1. Pick a new version number according to [semver][semver] rules:
-   the PR introduces or the bug it is fixing as well as the PR number and related issue number
+   `git tag vMAJOR.MINOR.PATCH`
-   if possible
+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.
+3. If you are a first time contributor add your name to the list of
-4. Add some non regression tests on:
+   contributors.
-  - 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
+# Preparing a release
-[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
+1. Set a tag with the version number in Git.
-  [here](https://github.com/vimwiki/testwikis).
+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.
 
-# More info and advice for (aspiring) core developers
+[semver]: https://semver.org/
-
-- 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 : -->

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",

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

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
+" Set to version number for release:
-let s:plugin_vers = 2.5
+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,9 +209,7 @@ endfunction
 " Echo vimwiki version
 " Called by :VimwikiShowVersion
 function! s:get_version() abort
-  if s:plugin_vers != -1
+  echo 'Version: ' . s:plugin_vers
-    echo 'Stable version: ' . string(s:plugin_vers)
-  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')
@@ -222,8 +220,7 @@ function! s:get_version() abort
     echo 'Revision: ' . l:plugin_rev
     echo 'Date: ' . l:plugin_date
   else
-      echo 'Unknown version'
+    echo 'Unable to retrieve repository info'
-    endif
   endif
 endfunction
 

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