This document describes tools, tasks and workflow that one needs to be familiar with in order to effectively maintain this project. If you use this package within your own software as is but don't plan on modifying it, this guide is not for you.
Run unit tests locally using the npm test
command. Tests are also run
automatically on all branches using
Travis CI.
This extension is published at https://marketplace.visualstudio.com/items?itemName=pranayagarwal.vscode-hack.
To push a new release, follow these steps:
- Make sure the
master
branch is up to date with all changes and has been tested. - Merge a new commit with the following changes:
- Update the version in
package.json
by following the versioning guide below - Re-run
npm install
to update package-lock file version and regenerateNOTICE.md
- Add a description of all changes since the last release in
CHANGELOG.md
- Add or update the "Latest releases" section in
README.md
with release highlights
- Update the version in
- Draft a new GitHub release:
- Releases should always target the
master
branch - Tag version and release title should both be in the format "v1.2.3", with
the version matching the value in
package.json
- Copy your new section from
CHANGELOG.md
in the release description
- Releases should always target the
- Once the release is published, a new Github build will automatically start.
Ensure that the build passes and a new
vscode-hack-[version].vsix
is added as an asset to the GitHub release page. - Publish the new version to the VS Code Marketplace. This can only be done from Pranay Agarwal's Microsoft account.
Even though this project is not published as an npm package, it uses a rough form of semver for versioning. Increment the MAJOR or MINOR version for feature additions, depending on size and impact, and PATCH version for bug fixes.
Releases are tagged in git and published on the repository releases page on GitHub.
All development should happen in feature branches. master
should be ready for
quick patching and publishing at all times.
Labels are used to run issues through an organized workflow. Here are the basic definitions:
bug
: A confirmed bug report. A bug is considered confirmed when reproduction steps have been documented and the issue has been reproduced.enhancement
orfeature request
: A feature request for something this package might not already do.docs
: An issue that is purely about documentation work.tests
: An issue that is purely about testing work.needs feedback
: An issue that may have claimed to be a bug but was not reproducible, or was otherwise missing some information.discussion
: An issue that is purely meant to hold a discussion. Typically the maintainers are looking for feedback in this issues.question
: An issue that is like a support request because the user's usage was not correct.semver:major|minor|patch
: Metadata about how resolving this issue would affect the version number.security
: An issue that has special consideration for security reasons.good first contribution
: An issue that has a well-defined relatively-small scope, with clear expectations. It helps when the testing approach is also known.duplicate
: An issue that is functionally the same as another issue. Apply this only if you've linked the other issue by number.external
: An issue that is caused by an external dependency and cannot be fixed here.
Triage is the process of taking new issues that aren't yet "seen" and
marking them with a basic level of information with labels. An issue should have
one of the following labels applied: bug
, enhancement
, question
,
needs feedback
, docs
, tests
, or discussion
.
Issues are closed when a resolution has been reached. If for any reason a closed issue seems relevant once again, reopening is great and better than creating a duplicate issue.
When in doubt, find the other maintainers and ask.