docs: Cleanup outdated docs

- remove docs for the removed bin commands
- update info on PRs and releasing

docs/pull-requests.md

@@ -3,49 +3,47 @@
 The only valid way of contribution to the project is through pull requests.
 A sole exception is a preparation of a new release
 (see [more about releasing](releasing.md#publishing-a-regular-release))
-where changelogs and bumped versions must be pushed directly to the main branch
-to avoid triggering release drafter and overwriting any manual changes made to
-the release notes (see below).
+where changelogs and bumped versions must be pushed directly to the main branch.
 
 PRs should be created against the `next` branch which is the main branch of the repository
 and basically the only branch with unlimited life-span.
 
-## Labels
+## Title
 
-We're using an automated [drafting of release notes](releasing.md#release-notes) / change log.
-For that to work, PRs should be tagged with labels describing the effect of its changes.
+PR titles should follow [conventionalcommits](https://www.conventionalcommits.org/).
+Because we are squashing the titles would usually be used for the final commit.
+So we need them to follow the convention.
 
-**Note:** We are using [our own fork of `release-drafter`](https://github.com/salsita/release-drafter) that solves following issues of the original:
-* https://github.com/release-drafter/release-drafter/issues/579 
-* https://github.com/release-drafter/release-drafter/pull/632    
-
-The labels have a following structure:
+As a summary, the overall structure is:
 
 ```
-<PACKAGE> <severity>
+<type>[optional scope][!]: <description>
 ```
-Where `<PACKAGE>` is one of:
-
-* `CORE` - `@spicy-hooks/core`
-* `OBSERVABLES` - `@spicy-hooks/observables`
-* `BIN` - `@spicy-hooks/bin` 
-* `UTILS` - `@spicy-hooks/utils`
-
-and `<severity>` is one of
 
-* `breaking` - breaking change in the public API
-* `feature` - new backward compatible feature or enhancement
-* `fix` - fix of existing functionality
+- **type** - Describes how the change affects semver
+  - `feat` or `feature` bumps _minor_ and is included in changelog
+  - `fix` bumps _patch_ and is included in changelog
+  - `perf` and `revert` should not affect version but are included in changelog
+  - Anything else is generally ignored. It has no effect on versioning and is excluded from changelog.
+    Any arbitrary type can be used but using one of the following is preferred:
+    - `docs`, `style`, `chore`, `refactor`, `test`, `build`, `ci`
+- **scope** - An optional identifier to highlight the affected part. It is wrapped in parentheses and directly follows the type.
+  - You can e.g. use the affected package name as scope. Or the nature of the change. Basically to provide more details
+- **!** - A breaking change. Reflected in versioning as _major_ bump. The change is then included in changelog regardless of its type.
+- **description** - Should be self-explanatory. A summary of the PR and its changes to be merged.
 
-**Example:** `CORE breaking` signalizes a breaking change in the `@spicy-hooks/core` package.
+Examples:
 
-If the PR combines more of the above scenarios, choose the one with the highest severity.
+- `chore(release): v1.0.0`
+- `fix: Update deps`
+- `feat(core)!: Drop support for IE11`
 
 ## Unit tests
 
 GitHub will automatically run unit tests upon opening, updating and re-opening any PR.
-These tests are required to pass before the PR can be merged into the `next` branch. 
+These tests are required to pass before the PR can be merged into the `next` branch.
 
 ## Merging
 
-We prefer squashing commits prior to merging, which is why the other options are disabled in our GitHub repository. 
+We prefer squashing commits prior to merging, which is why the other options are disabled in our GitHub repository.
+Please verify that the merge commit title follows conventionalcommits and that it relfect actual changes properly.

docs/releasing.md

@@ -1,101 +1,65 @@
 # Releasing
-Whole release process is almost entirely automated. The only part you need to do manually is to update
-changelogs and set proper versions. Fortunately, there's a script that you can run locally to handle this for you.
-The rest of the release process is triggered by publishing a new release in GitHub UI. This tags the current
-repository state with a provided version and performs all necessary release steps.
+
+Whole release process is entirely automated and handled by `lerna`.
 See [complete instructions](#publishing-a-regular-release) below.
 
 ## Release notes
-Upon closing any PR a release draft is created/updated containing a list of PRs merged
-since the previous release. The PRs are categorized based on [assigned labels](pull-requests.md#labels).
 
-Generated release notes should be treated as subject to manual edits prior publishing the release.
+Release notes are reused from generated changelog.
+A `GH_TOKEN` environment variable with valid token should be provided.
+Otherwise the release will not be created as part of the release process.
 
 ## Version
-The labels assigned to PRs are also used for suggesting a new version number. Based on which label
-is assigned, different part of the SemVer version is incremented:
 
-* `* breaking` - increment major version
-* `* feature` - increment minor version
-* any other label - increment patch version
+Commits and PR titles should follow [conventionalcommits](https://www.conventionalcommits.org/).
+The appropriate version bump is determined based on merged commits since the last release.
 
 **Important:** The same version is shared across all the packages. This means, that although
 we are following the SemVer conventions, there's no guarantee that an incremented major version
 of a particular package is triggered by a breaking change in that particular package.
 It is guaranteed though, that when the major version doesn't change,
-there has been no breaking change in any of the packages.   
+there has been no breaking change in any of the packages.
 
 ## Publishing a regular release
+
 Please follow the below steps when publishing a new release:
 
-1. Open the drafted release in GitHub UI
-    1. Finalize release notes
-    1. Check whether the suggested version matches expectations
-    1. Save the draft (**do not** publish yet)
 1. Ensure you have the latest `next` branch checked out locally
-    1. Run `yarn spicy prepare-release` in the root folder
-        * Changelogs will be automatically updated; edit manually if necessary
-        * Version number in all `package.json`s will be set to mach the release version
-    1. Commit and push the generated changes
-1. Open the drafted release in GitHub UI
-    1. Publish the release
-
-Couple of automated tasks will now run in a GH action:
-
-* current state of the repository is tagged with appropriate version
-* all packages are built
-* version from `package.json` is checked (must be equal to the one specified in the release)
-* unit tests are executed
-* all packages are published to NPM
-
-**Note:** It is a good practice to bump the `package.json` version after
-releasing in order to indicate that any new commit targets the next release.
-Bump a particular part of the SemVer version based on what you expect to
-deliver with the next release (it can always by changed later).
-Use `yarn spicy set-version X.X.X` to affect all `package.json`s in the project
-properly.
+1. Run `yarn lerna publish` in the root folder
+   - You should be presented with summary and info about the next version.
+     - Stop here and cancel if you think this is wrong. Otherwise confirm and continue.
+   - Changelogs will be automatically generated.
+   - Version number in all `package.json`s will be set to match the release version.
+   - `yarn.lock` will be updated accordingly.
+   - All packages will be built.
+1. You might be presented with OTP password to publish to NPM. Fill it in accordingly.
+   - All packages will be published to NPM.
 
 ## Releasing a hot-fix
+
 It happens quite often, that a critical bug is found while the `next` branch
 is full of new untested features and/or breaking changes. When that happens
 we have to release a hot-fix for the previous version rather than releasing
 the current state of `next`.
 
 In this case you should follow these steps:
-  
-1. Create a new branch based on the tag of the version you're going to hot-fix 
+
+1. Create a new branch based on the tag of the version you're going to hot-fix
 1. Commit and push the fix
-1. Open GH UI and manually draft a new release:
-    1. Set tag version to `vM.N.(P+1)` where `vM.N.P` is the version you're fixing
-    1. Set your new branch as the target.
-    1. Set the name of the release to match the tag name
-    1. Manually write down the release notes while following the structure of the auto-drafted releases
-    1. Save the draft (**do not** publish yet)
+   - Avoid any breaking changes. It could collide with regular releases.
 1. Make sure your branch is checked out locally
-    1. Run `yarn spicy prepare-release` in the root folder
-        * Changelogs will be automatically updated; edit manually if necessary
-        * Version number in all `package.json`s will be set to mach the release version
-    1. Commit and push the generated changes
-1. Open the drafted release in GitHub UI
-    1. Publish the release
-
-The same set of automated tasks as when publishing a regular release will be executed.
+1. Follow the same steps as for regular release
+   1. Run `yarn lerna publish` in the root folder
+   1. Confirm the next version
+   1. Enter the OPT password to publish to NPM.
 
-## Publishing a pre-release version 
+## Publishing a pre-release version
 
 It might not be possible to fully test some features of the packages without publishing them to NPM first.
 To avoid shipping unstable code to public, you can use a tagged version - e.g. `alpha` or `beta`.
 
-To publish a pre-release version, follow the instructions for releasing a hot-fix. Just make sure to:
-
-* set the tag version to `vM.N.P-<tag>.<tag-version>` where:
-    * `vM.N.P` is the next expected production release
-    * `<tag>` is `alpha` or `beta` (other strings are allowed, but discouraged)
-    * `<tag-version>` is a running number of this particular `alpha` or `beta` release (`0` for the first one, `1` for the second one etc.)
-* set the release name to the same as above
-* check the `This is a pre-release` checkbox
+To publish a pre-release version, you can mostly follow the instructions for releasing a hot-fix with some changes.
+You will basically replace the call to `yarn lerna publish`. For which you have two options:
 
-Submitting such a release will publish both SDK and CRA template packages to NPM using the
-[`--tag <tag>` option](https://docs.npmjs.com/cli/publish#description). This will make the packages available under
-`@spicy-hooks/<package>@vM.N.P-<tag>.<tag-version>` or simply `@spicy-hooks/<package>@<tag>` but will not affect the production
-(`latest`) channel.
+- `yarn lerna publish prerelease --preid TAG --dist-tag TAG` where the tag is the target you want to use. E.g. `alpha` or `beta`.
+- `./scripts/publish-prerelease.sh TAG` which has some basic options already predefined