Shouldn't an unreleased package start at initial version (0.0.0) rather than calculated from all changes?

[JeremyJonas]

semver/packages/semver/src/executors/version/utils/try-bump.ts

Line 54 in 1f2242f

New version will be calculated based on all changes since first commit.

If I have a package in my monorepo that does not have a release tag, I would expect that it would start at 0.0.0, however it starts at 1.0.0, assuming it is because in my long git history there are "BREAKING CHANGES" listed.

What is the use case for "New version will be calculated based on all changes since first commit. " rather than just 0.0.0?

Wondering if it would make sense to add an initialVersion option to the @jscutlery/semver:version, which if defined would by-pass the calculation of the default functionality. Additionally, this could act as a "minimum version" as well to support graduating a package from 0.0.0 => 1.0.0.

• If initialVersion is undefined, use current functionality
• If initialVersion is defined, and the new version is lower than the initialVersion, then the defined initialVersion is used

Currently, how do you graduate a package if entire release process is CI/CD driven? It would be great to simply update initialVersion=1.0.0 to graduate a package, which could get handled via CI/CD release without manually have to manage "releaseAs".

[ianldgs]

Related:
#444 (comment)
(set initial version on the package.json)