Skip to content

Commit

Permalink
v2.11.0 release prep
Browse files Browse the repository at this point in the history
  • Loading branch information
@PranayAgarwal
PranayAgarwal committed Sep 30, 2021
1 parent f9e396f commit b0b2f1a
Show file tree
Hide file tree
Showing 3 changed files with 177 additions and 76 deletions.
91 changes: 59 additions & 32 deletions .maintainers_guide.md
View file
Original file line number Diff line number Diff line change
@@ -1,70 +1,97 @@
# Maintainers Guide

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
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.

## Tasks

### Testing

Run unit tests locally using the `npm test` command. Tests are also run automatically on all branches using [Travis CI](https://travis-ci.org/slackhq/vscode-hack).
Run unit tests locally using the `npm test` command. Tests are also run
automatically on all branches using
[Travis CI](https://travis-ci.org/slackhq/vscode-hack).

### Releasing

This extension is published at https://marketplace.visualstudio.com/items?itemName=pranayagarwal.vscode-hack.
This extension is published at
https://marketplace.visualstudio.com/items?itemName=pranayagarwal.vscode-hack.

To push a new release, follow these steps:

1. Make sure the `master` branch is up to date with all changes and has been tested, and the Travis build is passing.
1. Make sure the `master` branch is up to date with all changes and has been
tested.
2. Merge a new commit with the following changes:
- Update the version in `package.json` by following the versioning guide below
- Update the version in `package.json` by following the versioning guide
below
- 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
- Add or update the "Latest releases" section in `README.md` with release
highlights
3. 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`
- 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
4. Once the release is published, a new Travis build will automatically start. Ensure that the build passes and the following build tasks are successful:
- A new `vscode-hack-[version].vsix` is added as an asset to the GitHub release page
- The new version of the extension is publised on the Visual Studio Marketplace (this may take some time)
4. Once the release is published, a new Travis build will automatically start.
Ensure that the build passes and the following build tasks are successful:
- A new `vscode-hack-[version].vsix` is added as an asset to the GitHub
release page
- The new version of the extension is publised on the Visual Studio
Marketplace (this may take some time)

## Workflow

### Versioning and Tags

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.
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.
Releases are tagged in git and published on the repository releases page on
GitHub.

### Branches

All development should happen in feature branches. `master` should be ready for quick patching and publishing at all times.
All development should happen in feature branches. `master` should be ready for
quick patching and publishing at all times.

### Issue Management

Labels are used to run issues through an organized workflow. Here are the basic definitions:
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` or `feature request`: A feature request for something this package might not already do.
- `bug`: A confirmed bug report. A bug is considered confirmed when reproduction
steps have been documented and the issue has been reproduced.
- `enhancement` or `feature 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.
- `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.
- `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.

## Everything else

Expand Down
Loading

0 comments on commit b0b2f1a

Please sign in to comment.