-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Maintainer's guide
See the Contributing.md for Vimium's design goals.
- 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.
This process is currently only done by Phil, Ilya or Steve.
-
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
and1.45.0
are taken to be identical, so for patch releases start with1.45.1
. -
Update the Changelog in README.md
You can see a summary of commits since the last version:
git log --oneline v1.45..
-
Push your commits
-
Create a git tag for this newly released version
git tag -a v1.45 -m "v1.45 release"
-
Push the new tag to the appropriate remote
git push origin v1.45
-
Run
cake package
-
Take the distributable found in
dist
and upload it here -
Update the description in the Chrome store to include the latest version's release notes
-
Celebrate