2gp: Package ancestry for patch versions

Question

Let's say we've just released 2.0 version of our 2gp package. And now we're releasing patch versions (one after another), e.g 2.0.1, 2.0.2, 2.0.3 and so on.

The question here: is there any difference in terms of upgradeability between using 2.0 as ancestor for all such patch versions VS linking next patch version to previous one (i.e. using 2.0.1 as ancestor of 2.0.2; 2.0.2 as ancestor of 2.0.3 and so on)?

Quote from official dx guide:

Ancestry isn't enforced for patch version upgrades that occur between package versions that share the same major and minor package version numbers

This means, I can upgrade between any 2.0.x patch versions (only downgrade is not allowed), and at the same time I can also upgrade any 2.0.x patch version to next major/minor, e.g. 2.1 or 3.0 (assuming they are using 2.0 as their own ancestor).

In such case, what is the purpose of organizing patch versions into hierarchies of different shapes if all of them behave the same way. Any use case when it can be really useful or am I missing something here?

Any help to shed light on this would be appreciated.

Answer 1

Patch versions for 2GPs are documented here. In this it is made clear the major and minor versions must match, the metadata must be compatible and they discuss that patches can be ancestors of other patches.

However, if you think about it, since patches cannot introduce new components, ancestry for patches only matters if such ancestry is enforced during upgrade installs. As you pointed out, the documentation makes it clear that this doesn't apply.

Thus the take away is that patches do not need to have ancestry between each other, just from the correct major/minor version that has the same set of package components.

Opinion: I would set explict patch-to-patch ancestry for clarity, especially when considering use of version tree diagram visualisation.

Note that to have patch versioning enabled, by Salesforce, your package must have passed security review - they will not enable it otherwise.