[GUIDELINE] let semantic-release do the releases

[UziTech]

We should not be manually publishing releases. Semantic release can handle everything from updating the changelog to creating a new release on github to publishing to apm.

In order for it to work we need to follow the conventional commit guidelines and let semantic-release run in actions.

1 fix: a commit of the type fix patches a bug in your codebase (this correlates with PATCH in semantic versioning).

2 feat: a commit of the type feat introduces a new feature to the codebase (this correlates with MINOR in semantic versioning).

3 BREAKING CHANGE: a commit that has a footer BREAKING CHANGE:, or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in semantic versioning). A BREAKING CHANGE can be part of commits of any type.

4 types other than fix: and feat: are allowed, for example @commitlint/config-conventional (based on the the Angular convention) recommends build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others.

5 footers other than BREAKING CHANGE: may be provided and follow a convention similar to git trailer format.

[vivi90]

@UziTech Yes, maybe i should use it.. :-)