Maintainer's guide

Maintainer's guide

See the Contributing.md for Vimium's design goals.

Process for handling tickets and pull requests

• PRs should be code reviewed. For small PRs, it's often faster to just merge the PR and then fix up the code, rather than leaving comments.
• Not every new feature PR should be merged in. A new feature has a cost -- it may make Vimium's feature set more bloated, or it may significantly increase the complexity of the code. See the contributors guide for some merge/no-merge heuristics. It's okay for some PRs to live on forks.
• If a bug isn't well-described or you think it's relatively unimportant, just close it. Having lots of github issues open makes it much harder to find the signal in the noise.
• If a question or unfixable bug gets filed more than once, add a FAQ entry for it so it's less likely to appear again.

How to release Vimium to the Chrome Store

This process is currently only done by Phil.

1. Ensure debug logging is not enabled in lib/utils.js

2. Increment the version number in manifest.json. If the major and/or minor version number changes, then users will be notified about the new release; otherwise they will not. 1.45 and 1.45.0 are taken to be identical, so for patch releases start with 1.45.1.

3. Update the Changelog in README.md

   You can see a summary of commits since the last version: git log --oneline v1.45..

4. Push commits, tag this version

(git pull before edits)
VERSION=v2.1.2
git commit -a -m "Bump version to $VERSION"
git push
git tag -a $VERSION -m "$VERSION release"
git push origin $VERSION
./make.js package

5. Take the distributable found in dist and upload to the Chrome Store
6. Upload to the Firefox addons store.
7. Upload to the Edge store
8. Celebrate