chore(docs): update release process and scripts in package.json and Release.md (#1662)

Author: JoannaSikora

docs/RELEASE.md

@@ -1,37 +1,127 @@
 # Release process of `design-system`
 
-## Releasing package to `npm` registry
+## Overview
+
+The release process follows the git-flow branching model and consists of three phases:
+1. **Start Release** - Create a release branch and bump package versions
+2. **Finish Release** - Merge to `main` (production) and create a GitHub release
+3. **Publish Release** - Publish packages to `npm` registry
+
+## Branch Structure
+
+This workflow uses git-flow conventions:
+- `main` - Production-ready code (stable releases)
+- `release/<DATE>` - Release branch named by date (e.g., `release/2024-01-15`) for preparing a new production release
+- Feature branches should be merged to `main` via PRs
+
+## Step 1: Start Release (Version Bumping)
 
 To deploy a package to the `npm` you need to be logged in as a `LiveChat` organization member. To confirm that you are logged in, you can use `npm whoami`. If you are not, use `npm login` and follow the instructions.
 
-The deployment process consists of only single command: `npm run deploy`. It will execute several sub-commands and you can run them separately if you wish, namely:
+### 1.1 Create release branch
 
-- `predeploy` - execute predeploy script
-  - `check` - fire up linter and unit tests that are provided per package
-  - `prettier` - format the code across the packages
-  - `build` - build the packages
-- `lerna version` - create a new version of the packages based on the conventional commits
-- `lerna publish` - publish the packages to `npm` registry
+Create a new release branch from the latest `main` branch with a date-based name:
 
-During the build phase,
-Lerna will ask you to confirm the version of the packages which Lerna chooses based on the conventional commits.
-You will need to confirm the version if everything is correct.
+```bash
+git checkout main
+git pull origin main
+git checkout -b release/2024-01-15
+```
 
-![img.png](assets/deploy_example.png)
+Replace `2024-01-15` with your current date in `YYYY-MM-DD` format. 
 
-### Disclamer
+### 1.2 Prepare release (bump versions)
 
-Keep in mind that a package won't be versioned if it has not changed. In the future a changed package will catch up with other packages in versioning. For example, assuming that version of package `react-components` is `1.1.3` but `icons` lag behind a bit and are at `1.1.0` because no changes has been made since two deploys. If you make some changes in `react-components` and in `icons` both packages will get `1.1.4` version.
+Run the prepare-release script to bump package versions:
+
+```bash
+npm run prepare-release
+```
+
+This command will:
+- Run `check` - execute linter and unit tests
+- Run `prettier` - format the code across packages
+- Run `build` - build the packages
+- Run `lerna version --conventional-commits --no-changelog --no-push` - create new package versions based on conventional commits
+
+During this phase, Lerna prompts to confirm the versions.
+
+Lerna creates the version commit and tags locally, but doesn't push.
+
+### 1.3 Commit and push version changes
+
+After Lerna determines the version, commit and push the version changes:
+
+```bash
+git add .
+git commit -m "chore(release): bump version to v<VERSION>"
+git push origin release/<DATE>
+git push origin --tags
+```
+
+Replace `<VERSION>` with the actual version proposed by Lerna (you'll see it in the commit) and `<DATE>` with your date-based branch name. Tags must be pushed explicitly with `git push origin --tags`.
+
+### 1.4 Create Pull Request
+
+Open a PR from your `release/<DATE>` branch to `main`:
+
+- **PR Title**: `chore(release): release v<VERSION>` (e.g., `chore(release): release v1.2.3`)
+- **PR Description**: Reference the actual version determined by Lerna and summarize the changes
+
+### 1.5 Get approvals and merge
 
-If you want to force versioning of a package you can use `--force-publish` flag with `lerna version` command instead of our `deploy` script. This will force Lerna to always version all packages, regardless of if they have changed since the previous release. Then they will all be published to the registry by `lerna publish from-git`.
+Get approvals and merge the PR to `main`. After merge, proceed to Step 2.
 
-## Updating documentation
+## Step 2: Finish Release (Publish to npm)
+
+After the release PR has been merged to `main`:
+
+### 2.1 Pull latest main and fetch tags
+
+```bash
+git checkout main
+git pull origin main
+git fetch --tags
+```
+
+### 2.2 Publish packages to npm
+
+Publish the packages to npm registry:
+
+```bash
+npm run deploy
+```
+
+This runs `lerna publish from-package`, which:
+- Reads versions from `package.json` files
+- Publishes packages with bumped versions to npm
+- Does not create or push tags (already on remote from Step 1)
+
+### 2.3 Create GitHub Release
+
+On GitHub, add the release with the correct version and changelog:
+
+- The release should reference the tag created in Step 1 (e.g., `v1.2.3`)
+- Tag is already on `main` from Step 1
+- Use the tag as the release name (e.g., `v1.2.3`)
+- Title: "What's Changed" or "Release v<VERSION>"
+- In the changelog, include:
+  - Packages changed
+  - Pull request links
+  - Issue references
+  - Author information
+  - Follow the style used in previous releases
+
+
+## Important Notes
+
+### Branch naming
+
+Release branches are named with the current date (e.g., `release/2024-01-15`) in `YYYY-MM-DD` format since the actual version is determined later by Lerna based on conventional commits.
+
+### Package versioning behavior
+
+Keep in mind that a package won't be versioned if it has not changed. In the future a changed package will catch up with other packages in versioning. For example, assuming that version of package `react-components` is `1.1.3` but `icons` lag behind a bit and are at `1.1.0` because no changes has been made since two deploys. If you make some changes in `react-components` and in `icons` both packages will get `1.1.4` version.
 
-On `Github` add the release with correct version and change-log.
+If you want to force versioning of a package you can use `--force-publish` flag when running the prepare-release script. This will force Lerna to always version all packages, regardless of if they have changed since the previous release.
 
-- Tag is added automatically by [lerna](https://github.com/lerna/lerna), remember to target `main` branch.
-- The name of the release is the name of the version/tag (eg. `v1.1.0`)
-- First paragraph title can be set to `What's Changed`.
-- In the change-log mention packages changed, link the pull requests and respective issues that are part of a release. Please follow the style used for previous releases (including author, PR, issue, and title info).
-  Example of correctly filled release note:
-  <img width="894" alt="example of release docs in GitHub" src="https://user-images.githubusercontent.com/7773964/182624431-232d6cea-9d0c-4455-afd9-365c88a1ab57.png">

package.json

@@ -22,10 +22,8 @@
     "test:watch": "lerna run test:watch --parallel",
     "prettier": "prettier --write packages",
     "check": "run-s lint test",
-    "predeploy": "npm run check && npm run prettier && npm run build",
-    "deploy": "lerna version --conventional-commits --no-changelog && lerna publish from-package",
-    "predeploy:auto": "npm run predeploy",
-    "deploy:auto": "lerna version --conventional-commits --no-changelog --yes && lerna publish from-package --yes"
+    "prepare-release": "npm run check && npm run prettier && npm run build && lerna version --conventional-commits --no-changelog --no-push",
+    "deploy": "lerna publish from-package"
   },
   "repository": {
     "type": "git",