chore: adjusted README docs

README.md

@@ -27,7 +27,7 @@ for [Conventional Commits](https://www.conventionalcommits.org/) with support fo
 ## Inputs
 
 | Input                  | Required | Default  | Description                                                             |
-|------------------------|----------|----------|-------------------------------------------------------------------------|
+| ---------------------- | -------- | -------- | ----------------------------------------------------------------------- |
 | `prefix`               | `false`  | `v`      | The prefix that should be prepended to the version.                     |
 | `suffix`               | `false`  | `hotfix` | The suffix that should be incremented / appended to the version.        |
 | `only-increase-suffix` | `false`  | `false`  | Increment the suffix if any changes got detected.                       |
@@ -36,7 +36,7 @@ for [Conventional Commits](https://www.conventionalcommits.org/) with support fo
 ## Outputs
 
 | Output         | Description                           |
-|----------------|---------------------------------------|
+| -------------- | ------------------------------------- |
 | `version`      | The next version, without the prefix. |
 | `version-name` | The next version, with the prefix.    |
 | `has-changes`  | If any relevant changes got detected. |
@@ -57,16 +57,9 @@ docker run get-release-version-action:local
 
 ## Testing
 
-1. Create a GitHub repository with a default branch (eg. by creating a README.md).
-2. Create a `.test.env` file in the repository root and set the `TEST_REPOSITORY_URL` variable to the repository created
-   in step 1.
-3. Run the test script with `bash test.sh`.
-4. The test files are available in the folder `test`. There is also a debug log there.
-5. To exit the test and delete all files, press any key in the terminal.
-6. After the test, delete the GitHub repository.
-   The test needs a fresh repository because it uses tags to determine the next version and creates a new tag for the
-   new version,
-   so if the repository already has tags, the output version is not the one expected in the test script.
+1. Run the test script with `bash test.sh`.
+2. The test files are available in the folder `test`. There is also a debug log there.
+3. To exit the test and delete all files, press any key in the terminal.
 
 ## FAQ
 
@@ -77,3 +70,45 @@ If the version number is not incrementing, please check the following points:
 - The commit messages **must** follow the [Conventional Commits](https://www.conventionalcommits.org/) specification
 - Cleanup the tags in the repository - that means that you need to go to the `All tags` overview and delete all tags
   which have **not** the `Verified` badge
+
+## Why did we implemented the sematic release by ourself?
+
+We had this issue, which finally led to the decision to implement the semantic release by ourself:
+
+### Release branch of stage (e.g. release-beta) is always creating hotfix versions
+
+#### How to reproduce
+
+1. Ensure that all branches (main, release, release-beta) are in sync
+
+2. Create a new commit `fix: hotfix` in the main branch
+
+3. Push the commit to the main branch
+
+4. Cherry-pick the commit to the release-beta branch
+
+5. After a bit waiting, merge from main into release => correct version gets created
+
+6. Merge from release into release-beta => hotfix version gets created (this could be because the cherry-pick duplicated the commit: <https://www.atlassian.com/git/tutorials/cherry-pick#:~:text=git%20cherry%2Dpick%20is%20a,be%20useful%20for%20undoing%20changes.>)
+
+- I can confirm by checking the history that there is a duplicated commit in the release-beta branch
+
+- For me the merge commit which is tagged to the newest version is the newest commit in the release-beta branch => don't understand why the duplicated commit is an issue
+
+#### What causes the issue?
+
+1. `Semantic-Release` is checking the commit history for the latest full release version
+
+   - Prints `algorithm.next_version: The last full ...` (e.g. `algorithm.next_version: The last full release was 0.1.2, tagged as 'v0.1.2'`)
+
+2. `Semantic-Release` is fetching all commits which are reachable from the current branch, but not from the latest full release version
+
+   - Using `git rev-list v0.1.2... --` to get the commits
+
+3. The unreachable commits are basically in this case two types:
+
+   1. The merge commits in the release-beta branch
+
+   2. The cherry-picked commit in the release-beta branch
+
+==> The issue is that the unreachable commits are from all time, not only from the last full release version