Perform an alpha version change only when versionable commit is present.

[CaffeinatedCodeMonkey]

I have a feature suggestion, based on a situation I'm running into.

Scenario:
I have an upper and lower pipeline for my applications, where the upper pipeline receives version updates based on conventional commits, and the lower receives alpha versions. With the upper pipeline, a new version and subsequent deployment via postTargets only occurs when there has been a versionable change. In contrast, the lower pipeline always receives a new alpha version, regardless of whether it contains a versionable change, due to calling it with --preid alpha --releaseAs prerelease. This increases the number of deployments that occur in non-release environments.

Suggestion:
Make the --preid argument independently usable, where, without being used in conjunction with --releaseAs, it will only apply a new version with a preid when there is a versionable change.

Current Alternatives:
The other approaches I've tried/considered are:

• Using affected instead of run-many --all when versioning, which mitigates the issue, but does not account for non-versionable commits or when an unchanged project shows up in the dependency graph.
• (UNTESTED) Supply an alternate tag prefix (so that it results in something like 'my-app.alpha.1.0.0') and omit --preid and --releaseAs, which would get the desired deployment behavior, but would likely result in release and non-release builds with versions that are indistinguishable.

I have other ideas to approach the issue, but they mostly get more elaborate, which I'd like to avoid. Of course, if there's already a way to achieve the desired result, and I've just passed right over it, please let me know!

[edbzn]

Hello, I think it's definitely a great feature, I also face this need in another project. I like your suggestion as well, let's do this!

[CaffeinatedCodeMonkey]

As an aside, my second alternate idea mostly works...

Supply an alternate tag prefix (so that it results in something like 'my-app.alpha.1.0.0') and omit --preid and --releaseAs, which would get the desired deployment behavior, but would likely result in release and non-release builds with versions that are indistinguishable.

But it runs into an issue when switching from tag prefix to tag prefix, where each time you switch it results in a patch bump. For example, if I run...

nx proj-a version --versionTagPrefix 'proj-a-alpha-' 
nx proj-a version --versionTagPrefix 'proj-a-'
nx proj-a version --versionTagPrefix 'proj-a-alpha-'
nx proj-a version --versionTagPrefix 'proj-a-'

... where the first command has an expected version bump, each of the following commands will cause patch bumps. Perhaps this is related to #374? I will mention this behavior in said issue, but I wanted to also mention it here.

[yjaaidi]

Hey @CaffeinatedCodeMonkey , this is an interesting issue.
Personally, as I am obsessed with symmetry between environments, I am not a big fan of prerelease in general 😉. As I am also obsessed with automation, I think that prerelease is not automatable as it's hard to tell if something should be prereleased or released. Nevertheless, this is just my extreme opinion I wanted to share here and this feature is common for many release workflows... so let's do it.

The way I see it is that there prerelease should not be an option for releaseAs as releaseAs is a synonym to "force release to be xxx" but I think that we just need to move this value to a distinct preRelease boolean option that would only bump if there are changes.
@CaffeinatedCodeMonkey , @edbzn, what do you think?

[CaffeinatedCodeMonkey]

@yjaaidi If the option switches to preRelease and that option begins producing prepatch, preminor, and premajor, would this example of version progression be accurate?

1.0.0                
# feat commit and versioning with --preRelease
1.1.0.alpha.0   
# fix commit and versioning with --preRelease
1.1.1.alpha.0   
# no changes and versioning, no --preRelease
1.1.1

[yjaaidi]

Very good question!

1.0.0                
# feat commit and versioning with --preRelease
1.1.0.alpha.0   ✅
# fix commit and versioning with --preRelease
1.1.1.alpha.0   ✅
# no changes and versioning, no --preRelease
1.1.1 🛑 no

The default behavior is that if there are no changes, nothing happens.
Currently, the only way to force bump when there are no changes is using releaseAs.

Now, the more I think about it, the more I think semver's prerelease kind of hacks the conventional commits automatic bump.

Expected Behavior

Let's assume the following scenario:

1. current version is 1.0.0
2. preid is "rc"
3. fix commit
4. prerelease should produce 1.0.1-rc.0
5. fix commit
6. prerelese should produce 1.0.1-rc.1 and not 1.0.2-rc.0 (otherwise, the prerelease index would always be 0 and we would create lots of prereleases that don't have a matching release
7. feat commit
8. prerelease should produce 1.1.0-rc.0 because we in fact gave up the 1.0.1 version as what we are preparing in the prerelease ends up being a feature
9. as many fix & feat commits as we want
10. prerelease should produce 1.1.0-rc.1
11. once we are ready, we want to release so we have to force release and it should produce 1.1.0

CLI API

Now, the question is, what's the best CLI API for this.
Well, I don't know 😅 but here are some constraints

• prerelease is only triggered if there are changes
• prerelease can be forced
• release can be forced

Maybe something like this:

--prerelease : bump to next prerelease depending on changes (e.g. given there are only fix commits since 1.0.0, 1.0.0 produces 1.0.1-rc.0 and 1.0.1-rc.11 => 1.0.1-rc.12)
--prerelease --releaseAs minor : force a minor prerelease (e.g. 1.0.0 => 1.1.0-rc.0 or 1.1.0-rc.0 => 1.2.0-rc.0 which would be a very weird usage but still possible) we would have to deprecated preminor etc... as its synonym to `--prerelease --releaseAs minor`
--prerelease --force : force a prerelease (e.g. 1.0.0 => 1.0.1-rc.0 or 1.0.1-rc.0 => 1.0.1-rc.1)
--force : force a release (e.g. 1.0.0 => 1.0.1 or 1.0.1-rc.0 => 1.0.1)```

What do you think?

The most important here is the `--prerelease` logic which should not only analyze the commits since the last version but since the last release as this scenario:
`fix commit => prerelease => feat commit => prerelease => fix commit => prerelease => release` should produce the following versions:
`                        1.0.1-rc.0                                   1.1.0-rc.0                                  1.1.0-rc.1          1.1.0`

[CaffeinatedCodeMonkey]

I like this approach a lot! It seems a very logical approach to getting prereleases and releases to work together harmoniously. My only remaining question would be on the use of --force. Your example of

--prerelease --force : force a prerelease (e.g. 1.0.0 => 1.0.1-rc.0 or 1.0.1-rc.0 => 1.0.1-rc.1)
--force : force a release (e.g. 1.0.0 => 1.0.1 or 1.0.1-rc.0 => 1.0.1-rc.1)

Is the second example of --force intended to be

1.0.0 => 1.0.1 or 1.0.1-rc.0 => 1.0.1

instead of

1.0.0 => 1.0.1 or 1.0.1-rc.0 => 1.0.1-rc.1

since this case is already handled under --prerelease --force? Or is there an additional case I'm not thinking of?

[yjaaidi]

It was just a test to make sure everyone is following...

... or more honestly, a copy paste error 🤣🤣🤣

If you caught this, it means that we are perfectly aligned.
I'll fix the example right now

[edbzn]

I love the idea exposed here! However, some points are not clear to me:

• The behavior of --force and --releaseAs are pretty close, do you think it will be clear for the users?
• What happens if --prerelease --force and --releaseAs are used together?
• Does --prerelease work in combination with --preid? otherwise, how do we decide between release identifiers?

[hcharley]

I think a FAQ answering @edbzn 's questions could be helpful:

I love the idea exposed here! However, some points are not clear to me:

• The behavior of --force and --releaseAs are pretty close, do you think it will be clear for the users?
• What happens if --prerelease --force and --releaseAs are used together?
• Does --prerelease work in combination with --preid? otherwise, how do we decide between release identifiers?