Feature Request - add ability to hold of 1.0.0 version bump

[shairez]

Hey friends!

What do you think about adding an option that prevents a major version?

Often when writing a new library you want to wait with the 1.0.0 release
prerelease has it's issues where you need to specify the prerelease prefix to get automatic updates

I thought about creating a PR that adds an option to make Majors into minors

So whenever semver returns "major" as the suggested bump, it'll turn it into minor

WDYT?

[edbzn]

Hey @shairez

Often when writing a new library you want to wait with the 1.0.0 release

0.x.y versions are for the initial development stage, where you can introduce breaking changes, but actually, if a breaking change is introduced in the commit history, semver automatically bumps to a major which results in v1.0.0. This is your problem, right?

What do you think about adding an option that prevents a major version?

It feels like a workaround because if we add this new option, ignoring the fact that there are already too many options, you will need to remove it manually when you want to go v1.0.0, which is not ideal for automation, but on other hand, I understand the need, maybe we can find another approach to solve this?

[shairez]

for now I settled on manually forcing a "patch" version for all packages.. but I'd like some how to convey that breaking changes will be done by increasing the minor (until 1.0.0)...

so it's manual either way, just looked for an option to make it a bit more automatic

not sure how to solve it in a different solution, but I understand if you don't want to pollute your configuration options more, I think it's a common enough use case for open source libraries, but maybe it's not the majority.

[edbzn]

I think the ability to introduce breaking changes without bumping to 1.0.0 is something needed, it could help dealing with the initial development phase. I'm just not enterly sure what's the clean way to do it.

An option could be detecting a special commit body to tells to semver when to bump to the 1.0.0 major version. For example we could detect BREAKING CHANGE 1.0.0: <message> while BREAKING CHANGE: <message> does not bump 0.x.y to 1.0.0. This would allow full automation as well as breaking changes in 0.x.y initial phase. The only thing I don't like is that we need to extend the semver spec. Do people will understand it?

In any case this feature is a breaking change which could only be introduced in the next major, but it's good to think about it now.

[shairez]

I think it's a common enough use case that worth maybe updating the original spec :)

or creating SEMVER for open source 😅

If you take for example - astro, sveltekit, solid start and qwik etc.. they all took their time before announcing 1.0

BTW, a suggestion for a commit message keyword could be: FIRST_MAJOR

[edbzn]

Note for #655:

// semver.config.js
if (versionable.name === 'xxx') {
  versionable.prereleasePrefix = 'alpha'
}

[yjaaidi]

Hey brother!!!

It's pretty funny... because guess what? I fell into the same trap today and released @jscutlery/operators 1.0.0 instead of 0.3.0 because it introduced a breaking change. https://github.com/jscutlery/devkit/releases

Well, we just had a discussion about this with @edbzn, and as he mentioned, with @jscutlery/semver 3.0 we are planning to get out of the false-feature-rich situations of heaving so many options and solve this with strategies.

👉 TL;DR: Meanwhile, the workaround that we've been using is that we simply don't use "BREAKING CHANGE" before hitting 1.0.0.
In fact, conceptually, there is no backward-compatibility in zero-version minors. So as anything could break at any moment.

That said, this is the theory and it would be nice to provide a nice changelog informing users of breaking changes in zero minors.

As an additional note to #655, this good be solved using either:

• (ideally) bump strategy: bump = zeroBumpStrategy()
• (not ideal but let's note this as it might help other situations) changelog strategy that would group changes using conventional commit types + tags! Cf. Group changelog items using custom tags #692

🤗

[shairez]

Thanks @yjaaidi

What I ended up doing is to define few targets, one for minor and one for patch, and we manually decide between them based on the changes we're doing 😅

[khalilou88]

I think the plugin need to hold any version not just the 1.0.0 version. Imagine if your add support for releasing versions from other branches than the main branch in the future. In this situation I want to hold the same version in that branches for fixes and small features.

[ianldgs]

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