Weird behaviour when nextVersion is equal current version

[perpetualKid]

Maybe I'm just doing wrong, but this behaviour looks weird to me:

From development branch which has "version": "2.0-dev.{height}" and run nbgv prepare-release --nextVersion 2.2 rc the development branch changes correctly to "version": "2.2-dev.{height}", and release branch to "version": "2.0-rc.{height}"

However, when (unintentionally) setting next version to the current version like run nbgv prepare-release --nextVersion 2.0 rc, the cli output is (kind of) correct

release/v2.0 branch now tracks v2.0-rc.{height} stabilization and release.
development branch now tracks v2.0-dev.{height} development.

but in reality it changes the prerelease tag in development branch also to "rc" so both development and release branch now have "version": "2.0-rc.{height}".
Aside that it should have warned me about not increasing the version, but I would not have expected the prerelease tag in development to be touched!

In fact there seems to be some checking already when the nextversion is set to something lower (ie going from 2.1 to 2.0):
"Cannot change version from 2.1-dev.{height} to 2.0-dev.{height} because 2.0-dev.{height} is older than 2.1-dev.{height}.", so it may need to check if it's lower or same version in that case.

[AArnott]

Thanks for reporting. And I think you have some good insights. I think I agree with the console output's alleged effect. Assuming your version.json is configured to say that any new version should start with dev as the prerelease tag. But I would support a warning being written to the console. And of course the behavior should match what the console claims to have done.

[perpetualKid]

Assuming your version.json is configured to say that any new version should start with dev as the prerelease tag.

indeed, this is the version.json

{
  "$schema": "https://raw.githubusercontent.com/dotnet/Nerdbank.GitVersioning/master/src/NerdBank.GitVersioning/version.schema.json",
  "version": "2.2.4-dev.{height}",
  "assemblyVersion": {
    "precision": "revision"
  },
  "gitCommitIdShortFixedLength": 8,
  "nuGetPackageVersion": {
    "semVer": 2.0
  },
  "publicReleaseRefSpec": [
    "^refs/heads/main$",
    "^refs/heads/master$",
    "^refs/heads/release/v\\d+(?:\\.\\d+)?(?:\\.\\d+)?$"
  ],
  "cloudBuild": {
    "setAllVariables": true,
    "buildNumber": {
      "enabled": true
    }
  },
  "release": {
    "branchName": "release/v{version}",
    "versionIncrement": "build",
    "firstUnstableTag": "dev"
  }
}```

[ap0llo]

I was curious and looked into this.

prepare-release actually does what is printed to the console. However, since the version on the development branch is already identical to the new version, this happens:

• On the development branch, there are no changes in the version.json file and thus no commit is created
• On the newly-created release branch, version.json is updated and committed
• When the branches are merged, there are no conflicts and git performs a fast-forward merge
• Both branches now point to the same commit and have the version of the release branch

I'm not sure what the best behavior in this situation is, but I think the prepare-release command should actually abort with an error if there are no changes on the development branch.

Also, it might be a good idea to disable fast-forward merges and always create a merge commit. This would at least make the change visible in the history.

[perpetualKid]

I'm not sure what the best behavior in this situation is, but I think the prepare-release command should actually abort with an error if there are no changes on the development branch.

thanks for checking. I agree, just aborting in that case should be fine and would have saved me from confusion. I can't see a real use case to reset the version.