0

As long as 2GP have a System Version Control as source of truth, it seems to me that the branching mechanism of SVC would be enough to create versions from another previous version of a 2GP. Having that said, why would be necessary to specify an ancestor for a particular 2GP version?

According to this document:

"Package ancestry allows you to create a tree-like version structure, and abandon a package version you no longer want to build on."

But I really can't get why ancestors are required to achieve the objective stated above. I do believe I'm not aware of a use case or feature of 2GP that would explains the need to have ancestors specified.

3
  • This explicit configuration is required because sfdx (and its package version creation commands) is not aware of branching in the VCS. Note that sfdx does not integrate directly with your VCS either, and you can choose what VCS you use (it doesn't even have to be a flavour of git and you don't have to use cloud based VCS either).
    – Phil W
    Sep 22, 2021 at 14:55
  • 2
    Ancestry is required in order to allow package upgrades. If you have two parallel "branches" for your package version "tree" you cannot perform install/upgrade that goes across these branches, only along them.
    – Phil W
    Sep 22, 2021 at 14:57
  • Constraint the package upgrade options sounds a fair reason for ancestors. Thank you @PhilW
    – Saulo
    Sep 22, 2021 at 15:21

2 Answers 2

2

Ancestry is required in order to allow package upgrades. If you have two parallel "branches" for your package version "tree" you cannot perform install/upgrade that goes across these branches, only along them.

In terms of the sfdx CLI commands for package version creation and management, these know nothing about any VCS you are using (indeed, you may not even be using one - would be weird, but possible).

2

In the classic packaging model, if you made a critical mistake that broke your package (e.g. you accidentally created an unwanted dependency), you had to engage Partner Support to roll back all subsequent versions of your package, which also required everyone using a broken version to have to uninstall as well.

With the new model, you can choose to have those customers that don't want to go through this process retain their version of the package, and all new customers, or customers that haven't upgraded down the broken path, to simply install the new version without affecting any of the other customers, and without getting Partner Support involved.

You can also use this to introduce the concept of a common ancestor package to diverge a product in two or more directions simultaneously. This might happen because you decided that you wanted to use LWC going forward, but wanted to reuse the Aura component names, or completely altering the API in incompatible ways, and the easiest way is to break off to a new branch.

The downside, though, is that the system can't automatically tell which version is an ancestor of another one. You need to tell it which branch it should be using. You do this by specifying ancestors. You can only upgrade a package version from one that has a common ancestor, so it's important to get this correct.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.