force\:package\:version:create doesn't bump version number after last created version has the branch changed using force\:package\:version:update

[sauloefo]

Summary

sfdx force:package:version:create doesn't create the version using the next build number if the last created package version has the branch changed by the command sfdx force:package:version:update

Steps To Reproduce:

1. In sfdx-project.json file, set versionNumber of the package to 0.0.0.NEXT;
2. run sfdx force:package:version:create -p id-of-the-package;
3. write down the id of the created version id-of-created-version;
4. run sfdx force:package:version:update -p id-of-created-version --branch any-text-here;
5. run sfdx force:package:version:create -p id-of-the-package;

Expected result

1. In sfdx-project.json, packageAliases should looks like:

   {
   "package-name@0.0.0-1": "id-of-the-first-version",
   "package-name@0.0.0-2": "id-of-the-second-version"
   }

2. In sfdx force:package:version:list -p id-of-the-package result should looks like

Version          Subscriber Package Version Id          Branch
0.0.0-1           id-of-the-first-version                       any-text-here
0.0.0-2           id-of-the-second-version

Actual result

1. In sfdx-project.json, packageAliases it looks like:

   {
   "package-name@0.0.0-1": "id-of-the-second-version"
   }

2. In sfdx force:package:version:list -p id-of-the-package result should looks like

Version          Subscriber Package Version Id          Branch
0.0.0-1           id-of-the-first-version                       any-text-here
0.0.0-1           id-of-the-second-version

System Information

• Which shell/terminal are you using? (e.g. bash, zsh, powershell 5, powershell 7, cmd.exe, etc.)

• If you are using sfdx

  • Run sfdx version --verbose --json

• If you are using sf

  • Run sf version --verbose --json

• Paste the output here

  {
  "cliVersion": "sfdx-cli/7.166.1",
  "architecture": "wsl-x64",
  "nodeVersion": "node-v16.14.0",
  "pluginVersions": [
  "@oclif/plugin-autocomplete 1.3.0 (core)",
  "@oclif/plugin-commands 2.2.0 (core)",
  "@oclif/plugin-help 5.1.12 (core)",
  "@oclif/plugin-not-found 2.3.1 (core)",
  "@oclif/plugin-plugins 2.1.0 (core)",
  "@oclif/plugin-update 3.0.0 (core)",
  "@oclif/plugin-version 1.1.2 (core)",
  "@oclif/plugin-warn-if-update-available 2.0.4 (core)",
  "@oclif/plugin-which 2.1.0 (core)",
  "alias 2.1.0 (core)",
  "apex 1.2.0 (core)",
  "auth 2.2.3 (core)",
  "community 2.0.1 (core)",
  "config 1.4.17 (core)",
  "custom-metadata 2.0.0 (core)",
  "data 2.1.2 (core)",
  "generator 2.0.2 (core)",
  "info 2.0.1 (core)",
  "limits 2.0.1 (core)",
  "org 2.2.0 (core)",
  "packaging 1.5.1 (core)",
  "schema 2.1.1 (core)",
  "signups 1.2.0 (core)",
  "source 2.0.13 (core)",
  "telemetry 2.0.0 (core)",
  "templates 55.1.0 (core)",
  "trust 2.0.3 (core)",
  "user 2.1.0 (core)",
  "@salesforce/sfdx-plugin-lwc-test 1.0.0 (core)",
  "salesforce-alm 54.8.1 (core)"
  ],
  "osVersion": "Linux 5.10.102.1-microsoft-standard-WSL2",
  "shell": "fish",
  "rootPath": "/home/saulo/.asdf/installs/nodejs/16.14.0/.npm/lib/node_modules/sfdx-cli"
  }

  Additional information

Feel free to attach a screenshot.

[github-actions[bot]]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[WillieRuemmele]

hey @sauloefo, we're currently working on the beta versions of the packaging commands and would love to fix it there. Could you please try using the force:package:beta:version:create command and see if this bug is still present?

[mshanemc]

@sauloefo all the beta has been live for awhile. Any luck? Is this still reproducible?

[github-actions[bot]]

This issue has not received a response in 7 days. It will auto-close in 7 days unless a response is posted.

[honeyverma]

Hi @mshanemc I am facing the same issue, actually we have CI-CD pipelines where we create workspace-server then install latest version of SFDX and then create new unlocked package version.

I also tried sfdx package version create ... but still same. It is crucial for us, and we want to track old versions because we need to follow SOX compliance.

[honeyverma]

HI @mshanemc do we have an update on this, it is getting critical for us as we are losing the tracking system, as we track all changes according to version

[shetzel]

@honeyverma - if this is a critical issue I would definitely go through the support channels so a case can be created for the packaging team, who is the best team to address this. Since there is no SLA with GitHub issues I'll do my best to at least reproduce this and if something stands out I'll try to get a fix in.

[shetzel]

@honeyverma - I reproduced the bug with CLI v7.197.8 and packaging plugin v1.16.5. I highly recommend opening a support case with the packaging team about this since that is how they intake issues.

[github-actions[bot]]

We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.

[honeyverma]

HI @shetzel thanks for the inputs and confirmation, I am going to open a ticket and refer this issue link as well.

[honeyverma]

Case number: 44544046

[ImJohnMDaniel]

Apologies for being late to this thread but what @sauloefo describes is exactly what I would expect the behavior to be.

If you build a package version with a branch designation of NULL, you will get package-name@0.0.0-1 and a corresponding record id (i.e., '04t000000000001AAA').

If you then update package version '04t000000000001AAA' to now have a branch, then the DEV HUB is aware of this change; not the local sfdx-project.json.

If you have not updated the alias in the sfdx-project.json, the alias is still package-name@0.0.0-1.

When you create a new package version with a branch designation of NULL, the DEV HUB will pick the next available version number for that MAJOR.MINOR.PATCH level specified in the sfdx-project.json ...on the branch designated in the command -- which is NULL. Since there is currently no package version on this branch designation of NULL where the MAJOR.MINOR.PATCH is "0.0.0", then the DEV HUB will create a package version and give it the version number which is "one build number higher than the previous version number with the same branch designation." Since, in this case, there are currently no package version builds on this MAJOR.MINOR.PATCH version on the branch designation of NULL, then the DEV HUB would assign the "build number" for this new package version to be "1"... thus the new package version number is "0.0.0-1" with Branch designation of NULL.

The CLI is updating the sfdx-project.json with the new package version number. It will work with the existing packageAliases in the sfdx-project.json. Since it treats that JSON object much like a "set", when it adds the new package version alias, it would -- in this scenario -- overwrite the original value.

The workaround that I would suggest is that when you manually add a branch designation to an existing package version in the DEV HUB, manually update the packageAlias of that package version to include the branch designation. In the example above, I would suggest renaming the packageAlias to be "package-name@0.0.0-1-any-text-here"

I would say that this very much is "working as designed".

Please let me know if you have questions.

cc: @WillieRuemmele , @mshanemc, @shetzel, and @honeyverma

[shetzel]

Link to known issue: https://issues.salesforce.com/issue/a028c00000ixJuFAAU/~ W-13185383

[shetzel]

The packaging team has determined that this behavior is working as designed. Packaging documentation will be updated to clarify this.