Add release-it to simplify the release process

.release-it.js

@@ -0,0 +1,19 @@
+module.exports = {
+  plugins: {
+    'release-it-lerna-changelog': {
+      infile: 'CHANGELOG.md',
+    },
+  },
+  git: {
+    commitMessage: 'v${version}',
+    tagName: 'v${version}',
+  },
+  github: {
+    release: true,
+    releaseName: 'v${version}',
+    tokenRef: 'GITHUB_AUTH',
+  },
+  npm: {
+    publish: false,
+  },
+};

RELEASE.md

@@ -1,22 +1,56 @@
-# Release Instructions
+# Release
 
-This project is using [TravisCI](https://travis-ci.org/) to automatically
-publish git tags to [npm](https://www.npmjs.com/).
+Releases are mostly automated using
+[release-it](https://github.com/release-it/release-it/) and
+[lerna-changelog](https://github.com/lerna/lerna-changelog/).
 
-Follow these steps to create a new release:
 
-1) `yarn changelog` – generates the changelog for the new release
+## Preparation
 
-2) Add generated changelog to `CHANGELOG.md` and commit with
-   `Update CHANGELOG` message 
+Since the majority of the actual release process is automated, the primary
+remaining task prior to releasing is confirming that all pull requests that
+have been merged since the last release have been labeled with the appropriate
+`lerna-changelog` labels and the titles have been updated to ensure they
+represent something that would make sense to our users. Some great information
+on why this is important can be found at
+[keepachangelog.com](https://keepachangelog.com/en/1.0.0/), but the overall
+guiding principle here is that changelogs are for humans, not machines.
 
-3) `yarn version` – updates the `version` property in the `package.json`
-   file and creates a new git commit and tag for the release
+When reviewing merged PR's the labels to be used are:
 
-4) `git push upstream master --follow-tags` – pushes the release commit and
-   tag to the `upstream` remote
+* breaking - Used when the PR is considered a breaking change.
+* enhancement - Used when the PR adds a new feature or enhancement.
+* bug - Used when the PR fixes a bug included in a previous release.
+* documentation - Used when the PR adds or updates documentation.
+* internal - Used for internal changes that still require a mention in the
+  changelog/release notes.
 
-5) Wait for TravisCI to finish the build, tests and deployment
 
-Note that for `yarn version` to work properly the `version` field should not
-be adjusted manually before the release.
+## Release
+
+Once the prep work is completed, the actual release is straight forward:
+
+* First, ensure that you have an environment variable with your GitHub token
+  setup as `GITHUB_AUTH`. This token will be used for generating your changelog
+  (unauthenticated requests to the GitHub API are heavily throttled) and for
+  creating the GitHub release. Only "repo" access is needed; no "admin"
+  or other scopes are required.
+
+* Next, ensure that you have installed your projects dependencies:
+
+```
+yarn install
+```
+
+* And last (but not least 😁) do your release:
+
+```
+yarn release
+```
+
+[release-it](https://github.com/release-it/release-it/) manages the actual
+release process. It will prompt you to to choose the version number after which
+you will have the chance to hand tweak the changelog to be used (for the
+`CHANGELOG.md` and GitHub release), then `release-it` continues on to tagging,
+pushing the tag and commits, etc. Finally GitHub Actions will build the commit
+and push the release to npm.

package.json

@@ -16,6 +16,7 @@
     "build": "ember build",
     "changelog": "lerna-changelog",
     "lint": "eslint . --cache",
+    "release": "release-it",
     "start": "ember server",
     "test": "npm run test:keep && npm run test:strip",
     "test:all": "ember try:each",
@@ -54,7 +55,9 @@
     "mocha": "8.3.2",
     "multidep": "2.0.2",
     "qunit": "2.15.0",
-    "qunit-dom": "1.6.0"
+    "qunit-dom": "1.6.0",
+    "release-it": "14.6.1",
+    "release-it-lerna-changelog": "3.1.0"
   },
   "engines": {
     "node": "10.* || >= 12.*"