5

I have a package version 1.2.0.0 and I've created a patch with some hotfixes which I packaged as 1.2.1.0 (updated the patch version). During packaging of 1.2.1.0 the ancestor version specified is version 1.2.0.0. All of the versions are released - in order for package ancestry to work.

The question I have is the following. What do I need to specify as the ancestor for version 1.3.0.0 once more code changes are merged and a decision to package it is made? Do I specify 1.2.0.0 or 1.2.1.0? What if I have another patch release version 1.2.2.0 afterwards?

Will it be possible to upgrade from 1.2.1.0 to 1.3.0.0 if they both share the same ancestor, i.e. 1.2.0.0?

Edit: The documentation specifies:

1.2.0.3 -> 1.3.0.7

No. To upgrade to 1.3.0.7, package version 1.2.0.3 must be the specified ancestor, or the specified ancestor must be a descendent of 1.2.0.3.

Would this mean that in my example the common ancestor should be 1.2.0.0 and this would allow the package upgrade?

Improve this question
1
  • 2
    Note the 0.3.3.6 -> 0.3.5.2 example in the documentation you cited. This says "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."
    – Phil W
    Nov 26, 2020 at 22:48

1 Answer 1

Reset to default
3

Scenario 1 - 1.2.1.0 as your ancestor for the next minor release i.e 1.3.0.0

Let's consider the scenario if you specify 1.2.1.0 as your ancestor for the next minor release i.e 1.3.0.0

In this scenario if you have a subscriber org on 1.2.0.0 you will have to install the 1.2.1.0 and then 1.3.0.0 since you specified the ancestor as 1.2.1.0

The above is definitely not one would want if you plan to merge your patch into the next minor release.

Scenario 2 - 1.2.0.0 as your ancestor for the next minor release i.e 1.3.0.0

In this you can upgrade your org with package 1.2.0.0 to the next minor or update the org which has the patch 1.2.1.0 because 1.2.1.0 had the ancestor as 1.2.0.0.

So yes 1.2.0.0 is the common ancestor here.

In all normal cases if you plan a new minor release I would keep the previous major.minor as the ancestors.

Let's say you plan further patches (1.2.2.0, 1.2.3.0) you can specify ancestors as the previous patch versions for patches.

I suggest you look into Semantic Versioning to better understand when to go for patch vs Minor release vs Major

Improve this answer
1
  • Thanks! I'm familiar with semver, but wasn't sure if SalesForce actually works that way as well.
    – mcekol
    Nov 27, 2020 at 8:29

You must log in to answer this question.

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