We are creating a managed package to list it to Apex Exchange. We are having issues to test our releases with beta packages because as we all know that we can't upgrade a beta package, so we need to spend a lot of time for manual steps,

What we have decided is to create release versions with the latest changes and the stable ancestorVersion. For example,

The stable release version is - 1.1.0

We are creating manage release version (1.2.0, 1.3.0, 1.4.0 .....) until 2.0.0 with the ancestor version 1.1.0

My question is can we upgrade,

1.1.0 -> 1.2.0
1.1.0 -> 1.3.0
1.1.0 -> 1.4.0

I know that we can't upgrade,

1.2.0 -> 1.3.0, 1.4.0, 1.5.0, ....
1.3.0 -> 1.4.0, 1.5.0, 1.6.0, ...

Is it a good approach or is anyone have any other options that we can use?

  • 1
    Since this is to be a new package, I would have thought you'd want to use versions with direct ancestry with the previous "release", assuming each temporary "release" is compatible, starting with 0.1 and going up through 0.2, 0.3 etc. If you have breaking changes to discard, you'll always break the ability to upgrade anyway. When you get to your actual release you can have no ancestry and start at 1.0 on the assumption you will effectively throw away the 0.x versions and won't need any of the environments on which you did the earlier testing.
    – Phil W
    Apr 29, 2021 at 7:09

1 Answer 1


You need to use patch versions to enable upgrading without ancestry requirements. If you look at the documentation, they have a chart that demonstrates this.

Sample Ancestry Hierarchy

And they explain:

Upgrade From Upgrade To Will This Package Upgrade Succeed?
... ... (other examples) Yes. Ancestry isn’t enforced for patch version upgrades that occur between package versions that share the same major and minor package version numbers. In this example, both versions begin with 0.3.

So, your packaging strategy should be more like:

Stable Patch 1 Patch 2 Patch 3 ...
1.1.0 1.1.1 1.1.2 1.1.3 ...
1.2.0 1.2.1 1.2.2 1.2.3 ...

You should only move up to x.x.0 versions when they are stable versions, and not use minor releases as "patches" with a common ancestor. That's not how the system is designed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .