ci(semantic-release): #67: rewrite workflow of releases

.github/workflows/publish-release.yml

@@ -5,6 +5,7 @@ on:
     branches:
       - master
       - 'release/*'
+      - develop
 
 permissions:
   contents: write
@@ -80,17 +81,26 @@ jobs:
           virtualenvs-create: true
           virtualenvs-in-project: true
 
-      - name: Semantic Version Release
-        id: release
-        uses: python-semantic-release/python-semantic-release@v8.3.0
+      - name: Set up Node.js
+        uses: actions/setup-node@v6
         with:
-          github_token: ${{ secrets.GITHUB_TOKEN }}
-          git_committer_name: "github-actions"
-          git_committer_email: "actions@users.noreply.github.com"
+          node-version: 24.15.0
 
-      - name: Upload to GitHub Release Assets
-        uses: python-semantic-release/publish-action@v10.4.1
-        if: steps.release.outputs.released == 'true'
-        with:
-          github_token: ${{ secrets.GITHUB_TOKEN }}
-          tag: ${{ steps.release.outputs.tag }}
+      - name: Install semantic-release and plugins
+        run: |
+          npm install \
+            semantic-release@25.0.3 \
+            @semantic-release/exec@7.1.0 \
+            @semantic-release/commit-analyzer@13.0.1 \
+            @semantic-release/release-notes-generator@14.1.1 \
+            @semantic-release/changelog@6.0.3 \
+            @semantic-release/git@10.0.1 \
+            @semantic-release/github@12.0.8 \
+            conventional-changelog-conventionalcommits@9.3.1 \
+            @kilianpaquier/semantic-release-backmerge@1.7.5            
+
+      - name: Semantic Version Release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          npx semantic-release

CONTRIBUTING.md

@@ -4,7 +4,13 @@ To contribute to the c2pie package development, you can use one of the following
 
 ### General principles
 
-🔸 Use Conventional Commits (e.g., `feat:`, `fix:`, `style(ruff):`, `ci:`).  
+🔸 Use Conventional Commits (e.g., `feat(scope):`, `fix:`, `style(ruff):`, `ci:`). 
+
+🔸 Name branches using Git Flow convention with the issue number and short description
+(e.g., `feature/#67-add-validation`, `fix/#42-crash-on-empty-input`).
+
+🔸 Name pull requests using Conventional Commits format with the issue number
+(e.g., `feat(api): #67 add ingredient validation`, `fix(parser): #42 handle empty input`).
 
 🔸 Run `Lint and Format` task before committing.  
 
@@ -89,4 +95,66 @@ ruff check . --fix
 
 The latter option is also available via the VC Code task `Lint and Format`
 
-<br>
+<br>
+
+## Release Process
+
+Releases are fully automated via [semantic-release](https://semantic-release.gitbook.io/). No manual version bumping or tagging is needed.
+
+### Release triggers
+
+A release is created automatically on push to `master`, `release/*`, or `develop` if there are commits with a release-triggering type (`feat`, `fix`, `docs`, `refactor`) since the last release.
+
+### Version tags
+
+```
+develop        →  1.4.0-alpha.1, 1.4.0-alpha.2, ...
+release/1.4.0  →  1.4.0-rc.1, 1.4.0-rc.2, ...
+master         →  1.4.0
+```
+
+### Preparing a release
+
+1. Create a `release/X.Y.0` branch from `develop`.
+
+2. Only bug fixes and release-related commits are made on this branch. Each push generates a new RC: `1.4.0-rc.1`, `1.4.0-rc.2`, etc.
+
+3. When the release is ready, merge into `master` via PR. The stable release `1.4.0` is created automatically on merge.
+
+### Preparing a alpha release 
+
+1. Create a `feature/*` or `fix/*` branch from `develop`.
+> Note: naming of branch will be with number of issue and name of issue (e.g. `feature/#67-add-feature`).
+
+2. Make the changes.
+
+3. When changes are made, merge into `develop`. The alpha release `1.4.0-alpha.1` is created automatically on merge.
+
+### Version bump
+
+| Commit type | Bump | Example |
+|---|---|---|
+| `fix` / `docs` / `refactor` | patch | `1.4.0 → 1.4.1` |
+| `feat` | minor | `1.4.0 → 1.5.0` |
+| `feat!` / `BREAKING CHANGE` | major | `1.4.0 → 2.0.0` |
+
+### Backmerge
+
+After every release on `master` or `release/*`, semantic-release automatically merges the release commit back into `develop`. This keeps `develop` in sync with the latest released version and ensures that the release commit (with updated `CHANGELOG.md` and `pyproject.toml`) is not lost.
+
+| Release on | Merged back into |
+|---|---|
+| `master` | `develop` |
+| `release/*` | `develop` |
+
+> Note: Backmerged commit to the `develop` branch has the `[skip ci]` tag, so a new alpha release from the `develop` branch will not be created.
+
+### PyPI Publishing
+
+Every release (stable, RC, and alpha) automatically triggers the `publish-package.yml` workflow. 
+
+Workflow consists of two jobs:
+
+1. **Build** — installs Poetry and builds the package via `poetry build`
+2. **Publish** — uploads the built distributions to [PyPI](https://pypi.org/p/c2pie)
+   using the official [`pypa/gh-action-pypi-publish`](https://github.com/pypa/gh-action-pypi-publish) action