Skip to content
This repository has been archived by the owner on Apr 24, 2023. It is now read-only.

Latest commit

 

History

History
105 lines (72 loc) · 5.5 KB

maintainers_guide.md

File metadata and controls

105 lines (72 loc) · 5.5 KB
Raw

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 not for you.

Tools

All you need to work on this project is a recent version of Deno

Tasks

Testing

Test can be run directly with Deno:

deno task test

You can also run a test coverage report with:

deno task coverage

Lint and format

The linting and formatting rules are defined in the deno.jsonc file, your IDE can be set up to follow these rules:

  1. Refer to the Deno Set Up Your Environment guidelines to set up your IDE with the proper plugin.
  2. Ensure that the deno.jsonc file is set as the configuration file for your IDE plugin
    • If you are using VS code this is already configured in .vscode/settings.json

Linting

The list of linting rules can be found in the linting deno docs. Currently we apply all recommended rules.

Format

The list of format options is defined in the deno.jsonc file. They closely resemble the default values.

Releasing

Releases for this library are automatically generated off of git tags. Before creating a new release, ensure that everything on the main branch since the last tag is in a releasable state! At a minimum, run the tests.

To create a new release:

  1. Create a new GitHub Release from the Releases page by clicking the "Draft a new release" button.
  2. Input a new version manually into the "Choose a tag" input. You can start off by incrementing the version to reflect a patch. (i.e. 1.16.0 -> 1.16.1)
    • After you input the new version, click the "Create a new tag: x.x.x on publish" button. This won't create your tag immediately.
    • Auto-generate the release notes by clicking the "Auto-generate release notes" button. This will pull in changes that will be included in your release.
    • Flip to the preview mode and review the pull request labels of the changes included in this release (i.e. semver:minor semver:patch, semver:major). Tip: Your release version should be based on the tag of the largest change, so if this release includes a semver:minor, the release version in your tag should be upgraded to reflect a minor.
    • Ensure that this version adheres to semantic versioning. See Versioning for correct version format. Version tags should match the following pattern: 1.0.1 (no v preceding the number).
  3. Set the "Target" input to the "main" branch.
  4. Name the release title after the version tag.
  5. Make any adjustments to generated release notes to make sure they are accessible and approachable and that an end-user with little context about this project could still understand.
  6. Make sure "This is a pre-release" is not checked.
  7. Publish the release by clicking the "Publish release" button!
  8. After a few minutes, the corresponding version will be available on https://deno.land/x/deno_slack_builder.

Workflow

Versioning and Tags

This project is versioned using Semantic Versioning.

Branches

Describe any specific branching workflow. For example: main is where active development occurs. Long running branches named feature branches are occasionally created for collaboration on a feature that has a large scope (because everyone cannot push commits to another person's open Pull Request)

Everything else

When in doubt, find the other maintainers and ask.