[Feature]: Make -Preview on stable versions create the next patch preview

[stiwicourage]

Summary

Make Update-NovaModuleVersion -Preview use a deterministic preview-track rule:

• on a stable version, increment the patch and add -preview
• on an existing preview version, continue the current behavior of incrementing the preview sequence

That would make -Preview consistently mean "stay on or enter the preview track".

Problem or use case

Today, Update-NovaModuleVersion -Preview -ContinuousIntegration can still infer a semantic minor bump from git history when the current version is stable.

That caused a real workflow problem in KeepAChangelog:

• main released 0.2.0
• the publish workflow then reset develop to the released main
• it ran Update-NovaModuleVersion -Preview -ContinuousIntegration
• the result became 0.3.0-preview

The expected post-release develop version was:

0.2.1-preview

For post-release automation, maintainers need -Preview on a stable version to be deterministic and move to the next patch preview, not re-run semantic history inference.

Proposed solution

Define -Preview with a more specific purpose:

1. Stable version + -Preview

   • 0.2.0 -> 0.2.1-preview

2. Preview version + -Preview

   • keep the current preview-increment behavior

3. Preview version without -Preview

   • remove the preview suffix and bump the version normally according to Nova's semantic version rules

This would let release workflows use:

Update-NovaModuleVersion -Preview -ContinuousIntegration

both to:

• enter preview mode from a fresh stable release, and
• continue preview mode when already on a preview version.

Alternatives considered

The current workaround is to hard-code the next patch preview version in workflow logic after a release from main.

That works for a single repository, but it pushes version-policy logic into each workflow instead of keeping the rule inside NovaModuleTools where the versioning behavior belongs.

Affected area

Publish or release flow

Related command or cmdlet

Update-NovaModuleVersion

Example usage

# stable -> next patch preview
Update-NovaModuleVersion -Preview
# 0.2.0 -> 0.2.1-preview

# preview -> next preview
Update-NovaModuleVersion -Preview
# 0.2.1-preview -> 0.2.1-preview2 (or current Nova preview increment format)

# preview -> normal release bump path
Update-NovaModuleVersion

Relevant project.json context

{
  "Version": "0.2.0"
}

Expected benefit

Better automation or CI/CD

Breaking change risk

Medium

Current NovaModuleTools version

N/A

Additional context

This came up while investigating the KeepAChangelog publish workflow.

After releasing 0.2.0 from main, the follow-up develop preparation step produced:

PreviousVersion : 0.2.0
NewVersion      : 0.3.0-preview
Label           : Minor
EffectiveLabel  : Minor
CommitCount     : 38
Applied         : True

That looks correct for generic semantic inference, but wrong for the intended "prepare the next develop preview immediately after a stable release" workflow.

Related investigation:

• Publish.yml bumps develop to 0.3.0-preview instead of 0.2.1-preview after main release KeepAChangelog#14

Pre-submit checklist

• I searched existing issues to avoid creating a duplicate.
• I explained the problem or use case, not just the desired solution.
• This is not a bug report or security vulnerability report.