I see a lot of people pushing a code base of "Happy Soup" of packages. However, there is a common dependency management use-case that I haven't seen a solution for.

Deployments that requirement multiple packages to be updated at once.

Take for example the following setup:

Package A 1.0.0

global class Foo {
   global static void doFoo() {}

Package B 1.0.0

global class Bar {
   global static void doBar() {

Now, lets say we need to update Foo.doFoo so it accepts a parameter:

global static void doFoo(String msg) {}

We'll also need to update doBar:

  global static void doBar() {
      A.Foo.doFoo('ello dingus');

And release a new version (2.0.0) for each package.

So how do we get these updates into our org? As far as I know, there isn't a way to deploy both packages in the same request (maybe I'm wrong?).

And we can't first publish Package A 2.0.0 because it is not compatible with Package B 1.0.0.

Is there a solution (other than just outright deleting Package B)?

2 Answers 2


On our product roadmap, we have plans to support installing and upgrading multiple packages in a single transaction.

Until that is available, would this multi-step process work for you?

1) Release Package A ver 1.1.0 that has both the methods - global static void doFoo() and global static void doFoo(String msg).

2) Release Package B ver 1.1.0 where doBar() invokes doFoo(String msg).

3) Release Package A ver 1.2.0 where you remove global static void doFoo().

4) In the installed org, install Package A ver 1.1.0, then Package B ver 1.1.0 and then Package A 1.2.0

  • Glad to hear this is on the roadmap, Dileep --- can you update the status of this Idea, or comment on whether you would allow customers to "bundle install" an ISV's package as well? success.salesforce.com/ideaView?id=08730000000jHCyAAM
    – zachelrath
    Nov 14, 2019 at 16:05
  • 1
    In this scenario this works ok because you can overload the method. In other scenarios, you would end up needing to re-create entire chains of dependencies!
    – NSjonas
    Nov 14, 2019 at 17:41

There is no neat way of doing this, but you can go old-school.

Upgrade all the packages in a sandbox, choosing to only compile the package when you install (which lets you make breaking changes sequentially).

Then, use a conventional deployment of the key cross-over classes Foo and Bar (or just all changes) to production. Since they're unlocked, you can change them outside of packaging.

Then install the packages to prod sequentially - which does nothing significant, but gets the version numbers right.

  • Seems like the best solution, yet tremendously unsatisfying. I can't imagine a CI pipeline being able to deal with this.
    – NSjonas
    Nov 14, 2019 at 17:38

You must log in to answer this question.

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