Cannot create new build version of a released package version

[jclappsy]

Note
Before you submit your issue, make sure that:

• You're using the latest version of Salesforce CLI.
• You've searched both open and closed issues for related posts.
• You've used the doctor command to diagnose common issues.
• You understand that GitHub Issues don't adhere to any agreement or SLA.
  • If you require immediate assistance, use official channels such as Salesforce Customer Support.

Summary

As of today, I cannot increment the build version number of a package if the package is already released

Example:

    {
      "path": "my-package",
      "package": "My Package",
      "versionName": "Summer '23",
      "versionNumber": "0.1.0.NEXT",
      "default": false
    },

When running: sf package version create --package "My Package", I would expect the build version number to be bumped to 0.1.0.2 but I receive the following error:

Can't create package version. A managed released package version with version number 0.1.0 already exists. For new package versions, use a version number that is higher than the latest managed released package version. Format package version numbers as major.minor.patch.build.

Here is a working example. 1.42.0.1 was in a released state on 2/6. I was able to run sf package version create --package "Working Example" multiple times to increment the build version number on 2/7. This is evident as the build version number is 4.

sf package version list --released --packages "Working Example" 
{
  "packageName": "Working Example",
  "packageVersion": "id",
  "version": "1.42.0.1",
  "CreatedDate": "2025-02-06 20:14"
}
sf package version list --packages "Working Example"
{
  "packageName": "Working Example",
  "packageVersion": "id",
  "version": "1.42.0.4",
  "CreatedDate": "2025-02-07 18:45"
}

Steps To Reproduce

IMPORTANT
Provide a repository that's configured to reproduce the issue. If you are unable to provide a repo, please explain why not. The more info we have from the start, the faster we can resolve your issue.
We may close your issue if you don't include proper instructions.

• Generate a project with sf project generate or fork dreamhouse-lwc.
• Provide detailed step-by-step instructions on how to reproduce the issue.

Tip

use sf doctor --create-issue to automatically fill the required information

Expected result

running sf package version create --package "My Package" on a released package should increment the build number if the version number in the sfdx-project.json file is in the following format: MAJOR.MINOR.PATCH.NEXT

Actual result

Package creation fails with the following error: Can't create package version. A managed released package version with version number 0.1.0 already exists. For new package versions, use a version number that is higher than the latest managed released package version. Format package version numbers as major.minor.patch.build.

Additional information

System Information

zsh

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.75.5",
  "nodeVersion": "node-v18.19.1",
  "osVersion": "Darwin 23.6.0",
  "rootPath": "/Users/name/.nvm/versions/node/v18.19.1/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.18 (core)",
    "@oclif/plugin-commands 4.1.18 (core)",
    "@oclif/plugin-help 6.2.23 (core)",
    "@oclif/plugin-not-found 3.2.38 (core)",
    "@oclif/plugin-plugins 5.4.28 (core)",
    "@oclif/plugin-search 1.2.19 (core)",
    "@oclif/plugin-update 4.6.27 (core)",
    "@oclif/plugin-version 2.2.21 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.31 (core)",
    "@oclif/plugin-which 3.2.26 (core)",
    "@salesforce/cli 2.75.5 (core)",
    "apex 3.6.8 (core)",
    "api 1.3.3 (core)",
    "auth 3.6.90 (core)",
    "data 4.0.7 (core)",
    "deploy-retrieve 3.18.0 (core)",
    "info 3.4.34 (core)",
    "limits 3.3.44 (core)",
    "marketplace 1.3.7 (core)",
    "org 5.2.25 (core)",
    "packaging 2.9.14 (core)",
    "schema 3.3.46 (core)",
    "settings 2.4.10 (core)",
    "sobject 1.4.49 (core)",
    "telemetry 3.6.31 (core)",
    "templates 56.3.35 (core)",
    "trust 3.7.59 (core)",
    "user 3.6.6 (core)"
  ]
}

[github-actions]

Hello @jclappsy 👋 It looks like you didn't include the full Salesforce CLI version information in your issue.
Please provide the output of version --verbose --json for the CLI you're using (sf or sfdx).

A few more things to check:

• Make sure you've provided detailed steps to reproduce your issue.
  • A repository that clearly demonstrates the bug is ideal.
• Make sure you've installed the latest version of Salesforce CLI. (docs)
  • Better yet, try the rc or nightly versions. (docs)
• Try running the doctor command to diagnose common issues.
• Search GitHub for existing related issues.

Thank you!

[github-actions]

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.

[michallachowski]

I can see the same issue in my organization - we're using a bit older cli version (@salesforce/cli/2.67.7), but everything was working properly until Spring'25 major release. It means to me it's more likely related to SF major release, rather than being an issue with cli implementation.
I've created a support case to ask them about details, with a reference to this issue, as details are described very precisely by @jclappsy. If I get any feedback from SF Support Team, I can share it with you here.

[jclappsy]

I can see the same issue in my organization - we're using a bit older cli version (@salesforce/cli/2.67.7), but everything was working properly until Spring'25 major release. It means to me it's more likely related to SF major release, rather than being an issue with cli implementation. I've created a support case to ask them about details, with a reference to this issue, as details are described very precisely by @jclappsy. If I get any feedback from SF Support Team, I can share it with you here.

Thanks @michallachowski. My current work around is to just increase the patch number of the released version to avoid increasing minor version for development.

[VivekMChawla]

@michallachowski and @jclappsy - The ability to create new builds of a package after a specific major.minor version was promoted was a bug that the packaging team fixed in Spring '24 (254). The behavior you're reporting is now working as designed.

Note: The packaging team will temporarily revert this change because of an unintentional side effect with unlocked packaging. Once that side effect is fixed, the behavior to block creation of new build versions after package version promotion will return.

I'm curious about your use case for the prior behavior. Maybe there's something else we can do to meet your needs?

[michallachowski]

@VivekMChawla thank you for clarifying the details. It makes sense to me to consider promoted (released) packages as "closed" - no further changes should be added / built under the same version number. However, I'm just surprised that this bug existed for years - so long that we all get used to it and started to treat it as an expected behavior. As a result, applying a fix was considered as a bug introduced recently 😉

Do you know when packaging team is going to revert this change? I'm asking because if it's expected to happen soon, then we may not be forced to make any ad-hoc changes in our development process (it would be nice to avoid that), but we get some time to properly align with that change before they re-apply the restriction again.

To give you a bit more details about the use case of prior behavior - probably the best scenario here would be to increase version number each time we build new package (eg. when PR is merged, there should be a pre-merge hook that updates version number). Currently we don't have such process implemented yet, so we usually do it only once, just before the "final build" of package that we're going to release to production. In the meantime, all other package versions created for the purpose of development and testing have the same major.minor.patch as the one already promoted in the previous release cycle.

[gretarvp]

This change significantly affects our development process because we update package versions when creating a release from the development trunk. What expected practices should be established to align with this versioning criteria?

What is the reason for setting that criteria? Is it so we don't hit the situation of trying to promote a built version that have the same major.minor.patch already promoted?

Was this decision explained or discussed within any community you can share?

[bdovh]

@michallachowski and @jclappsy - The ability to create new builds of a package after a specific major.minor version was promoted was a bug that the packaging team fixed in Spring '24 (254). The behavior you're reporting is now working as designed.

Note: The packaging team will temporarily revert this change because of an unintentional side effect with unlocked packaging. Once that side effect is fixed, the behavior to block creation of new build versions after package version promotion will return.

I'm curious about your use case for the prior behavior. Maybe there's something else we can do to meet your needs?

Hi @VivekMChawla , are you sure that the unintentional side effect on unlocked packages has been fixed?
I just received an error

Can't create package version. A managed released package version with version number 0.0.13 already exists. For new package versions, use a version number that is higher than the latest managed released package version. Format package version numbers as major.minor.patch.build.

for an unlocked package. Why this was working fine on Friday.