fix: do not require conventional commits for releases

[achingbrain]

Description

Removes the requirement to use conventional commits for releases because it prevents you from releasing 0.x.x of a module.

Motivation and Context

Some projects (such as the one I'm working on at the moment) want to use lerna to coordinate releases across multiple modules but cannot release v1 due to reasons out of our control - there is no code requirement to use version numbers generated by the conventional commits module, a manually chosen version number works just as well.

Fixes #2521

How Has This Been Tested?

I did a release of https://github.com/ipfs/js-ipfs - it prompted me to choose versions for the various packages, I did, they were published to npm, github releases and changelogs were created as expected.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[achingbrain]

I see lots of unrelated looking test failures locally, lots of:

    ValidationError: Branch 'master' doesn't exist in remote 'origin'.
    If this is a new branch, please make sure you push it to the remote first.

Might be because I'm running the tests in a fork?

[achingbrain]

@evocateur do you have any interest in this feature? I'm more than willing to investigate the test failures to finish this off but could you give me a nod as to whether this will be merged?

[evocateur]

@achingbrain Sorry for the delay.

I don't see this happening, chiefly because I don't understand how you proposed to read the minds of developers to create meaningful release notes without --conventional-commits enabled. I just merged #2486, does this not cover your use case? It enables 0.x. ranges to stay 0.x despite breaking changes when using --conventional-commits.

The tests are failing because your proposed patch is now generating changelogs by default for every release, implicitly depending on conventional commits to produce anything of value, yet not guaranteeing the intent with the required --conventional-commits flag.

[achingbrain]

You don't have to read their minds, just their commit messages. Maybe this PR has a bad title, the idea was to still use conventional commits, just don't try to guess the new version number.

Anyway the point is moot - it looks like #2486 solves my problem, I'll give that a go.

[ahmed2m]

@evocateur There is no workaround or any flag to still generate changelogs according to the detected or defined convention and prompting the user for each package bump instead of relying on the logic of the conventional commits/semVer?

I get the logical reasoning behind using the conventional commits in the first place is doing everything smoothly without developer interaction but there should be an option for an edge case or for someone who don't want to follow the semVer approach.