ci: Improve build system

re #188

.github/workflows/push.yml

@@ -2,9 +2,9 @@ name: Release
 on:
   push:
     branches:
-      - master
+      - main
       - next
-      - alpha
+      - develop
 
 jobs:
   build:

.prettierrc

@@ -1,6 +1,7 @@
 {
   "singleQuote": true,
   "trailingComma": "all",
+  "proseWrap": "always",
   "overrides": [
     {
       "files": "*.ts",

.releaserc.json

@@ -26,13 +26,17 @@
 				"message": "chore(release): ${nextRelease.version} [skip ci]\n\n${nextRelease.notes}"
 			}
 		]
-	],
+  ],
+  "defaultBranch": "main",
   "branches": [
     "+([0-9])?(.{+([0-9]),x}).x",
-    "master",
-    "next",
+    "main",
     {
-      "name": "alpha",
+      "name": "next",
+      "prerelease": true
+    },
+    {
+      "name": "develop",
       "prerelease": true
     }
   ]

CONTRIBUTING.md

@@ -2,39 +2,75 @@
 
 :+1::tada: Thanks for taking the time to contribute! :tada::+1:
 
-The following is a set of guidelines for contributing to the Electron website
-on GitHub. These are just guidelines, not rules, so use your best judgment and
-feel free to propose changes to this document in a pull request.
+The following is a set of guidelines for contributing to the Electron website on
+GitHub. These are just guidelines, not rules, so use your best judgment and feel
+free to propose changes to this document in a pull request.
 
 ## Issues and Pull Requests
 
-* If you're not sure about adding something, [open an issue](https://github.com/bjerkio/swedbank-pay-js/issues/new) to discuss it.
-* Feel free to open a Pull Request early so that a discussion can be had as changes are developed.
+- If you're not sure about adding something, [open an issue][] to discuss it.
+- Feel free to open a Pull Request early so that a discussion can be had as
+  changes are developed.
 
 ## Commit Messages and Pull Request Titles
 
-We use the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification to standardize our commit history. To enforce this convention on commit messages and/or pull request titles, we use the [Semantic Pull Requests](https://github.com/probot/semantic-pull-requests) bot.
+We use the [Conventional Commits][] specification to standardize our commit
+history. To enforce this convention on commit messages and/or pull request
+titles, we use the [Semantic Pull Requests][] bot.
 
-The commit message summary (or pull request title) is constructed by prepending the type of change being made (e.g., feat, fix, refactor), followed by an imperative, present tense sentence (without a period).
-Example: `fix: make header bold`.
+The commit message summary (or pull request title) is constructed by prepending
+the type of change being made (e.g., feat, fix, refactor), followed by an
+imperative, present tense sentence (without a period). Example:
+`fix: make header bold`.
 
-If you are still working on your pull request, prepend `WIP:` to indicate that it's work in progress.
+If you are still working on your pull request, prepend `WIP:` to indicate that
+it's work in progress.
 
 ### Pull Request Title
 
-Same as commit messages, prepend the type of change being made (refactor, fix, chore, feat, etc.) 
-Example: `docs: add linux setup instructions`
+Same as commit messages, prepend the type of change being made (refactor, fix,
+chore, feat, etc.) Example: `docs: add linux setup instructions`
 
 ## Documentation
 
-Most of the documentation are automatically generated. We utilize `typedoc` that uses tags inline
-with classes in order to generate. The nice thing about this is that documentation will be visible
-when using Typescript in editors as well.
+Most of the documentation are automatically generated. We utilize `typedoc` that
+uses tags inline with classes in order to generate. The nice thing about this is
+that documentation will be visible when using Typescript in editors as well.
+
+You can generate documentation with the following command:
+
+```shell
+▶ yarn generate-docs
+```
 
 However, we love to have examples and guides as well.
 
+## Releasing
+
+This package utilizes [semantic release][] to manage releasing. We have three
+release channels, `main`, `next` and `develop`. Our Github Actions workflow
+automatically releases a canary release based on the content at `develop` as
+long as at least one commit message follows [Conventional Commits][].
+
+When the team decides too, `develop` is merged into `next` or `main`, dependant
+on the changes.
+
+- `develop` should be considered as unstable code (not ready for production).
+  e.g. `v1.0.3-develop.5`
+- `next` used for the next major version. e.g. `v2.0.0-next.1`
+- `main` should be considered stable. e.g. `v1.0.3`
+
+These are all considered [release branches][] as per Semantic Release
+documentation.
+
 ## Need Help?
 
 If any of this information confusing, incorrect, or incomplete, feel free to
-[open an issue](https://github.com/bjerkio/swedbank-pay-js/issues/new)
-for help.
+[open an issue][] for help.
+
+[semantic release]: https://github.com/semantic-release/semantic-release
+[conventional commits]: https://www.conventionalcommits.org/en/v1.0.0/
+[open an issue]: https://github.com/SwedbankPay/swedbank-pay-js/issues/new
+[semantic pull requests]: https://github.com/probot/semantic-pull-requests
+[release branches]:
+  https://semantic-release.gitbook.io/semantic-release/usage/workflow-configuration#branch-types