fix(lerna): aggressive patch bump

[SudilHasithaCognite]

Addressing Lerna aggressive versioning

We restrict new npm releases to [release]-tagged commits because lerna is
quite aggressive in its versioning. Changes to any file not ignored by Lerna will
cause a PATCH bump. Markdown files and tests are ignored, but changing anything else,
like a comment in a source file, will trigger a new version,
irrespective of conventional commits.

References

1. Lerna documentation: https://github.com/lerna/lerna/tree/main/libs/commands/version#--no-git-tag-version

Expected behavior of the change

By using the implemented logic we can control the versioning and releasing of release candidates as below.

1. To keep versions constant and publish the release candidates package to npm in a release branch

• feat/fix/chore (xyz): feature/fix/chore keep constant and publish [release]

2. To increase the version and publish the release candidates package to npm in a release branch (chore will not increase the version since we are using --conventional-commits flag)

• feat/fix (abc): feature/fix increase version and publish [release] [bump-version]

3. To trigger and publish a job but not release (no versioning or publishing) in a release branch

• feat/fix (zqa): feature/fix no versioning or publishing

The effect of new release.yaml to master branch. Master is also add to alloweBranch list in lerna.json to facilitate the npm package releases.

1. PR merge without [release] won't update the version or publish to npm.

• feat/fix/chore (abc): feature/fix/chore no version update or publish

2. PR merge with [release] from release-nx to master, keep constant version, and publish to npm.

• feat/fix (xyz): feature/fix no version update and publish [release]

3. PR merge with [release][bump-version] from release-nx to master, patch version update, and publish to npm

• feat/fix (xyz): feature/fix version update according to patch(minor) [release][bump-version]

4. PR merge with [release] from release-nx to master with constant version and publish to npm.

• chore (kgb): constant version as release branch [release]
• NB: Before merging to master we have to manually remove rc tag from pacakage.json.

Experiments performed are added below. (play 2X or higher)

04_Moving_From_Conventional_Commit_to_Patch.webm
02_New_Release_Branch_Behavior.webm
03_Current_Master_After_Merging_Cannot_Publish.webm
01_Version_Error_Publishing_Main.webm

[EliasBjorne]

Im not too familiar with this setup, but from what I see, it seems like this changes a bit of the release logic. We should then also update the
CONTRIBUTING Readme
so it mirrors these changes. Both regarding to the logic we should have when we remove
--conventional-commits

The logic around bump-verion etc.

I'm not too opinionated on what the best release strategy is as long as it is well documented

[SudilHasithaCognite]

Im not too familiar with this setup, but from what I see, it seems like this changes a bit of the release logic. We should then also update the CONTRIBUTING Readme so it mirrors these changes. Both regarding to the logic we should have when we remove --conventional-commits

The logic around bump-verion etc.

I'm not too opinionated on what the best release strategy is as long as it is well documented

Updated the contributing guidelines.

[EliasBjorne]

I think we should add some details on how we want to work with release branches. In other repos I have worked with, all fixes are merged into master, and then fixes are cherry picked from master to release branches. We should have some documentation on how we want to do this?

[EliasBjorne]

Not sure I understand this sentence

[SudilHasithaCognite]

Sorry, my wording makes no sense here. This is to release patches and minor version updates to the stable release

[EliasBjorne]

What is the usecase for this? I think the most tidy thing is to always push things to master, and then cherry pick fixes from master to release branches. Do we want to do this? @BugGambit