Partial upgrade via `upgradeSequential` can result in bumping the version number incorrectly

[thomashoneyman]

I noticed an issue when scanning through #715 in which a partial upgrade via upgradeSequential can result in bumping the version number incorrectly.

Not a big deal, but basically upgradeSequential computes the next package-set version from the entire changeSet (including failed changes). So if the change set includes a failed major bump and only patch-level updates succeeded, the computed version can still jump major because it saw the failed major change. The resulting package set contents would only reflect patch updates, but the version would indicate a major change that never actually landed.

Ideally we would compute the next version from succeeded instead of the changeSet.

[thomashoneyman]

Relatedly, in upgradeSequential, the batch is ordered so dependencies come before dependents. That’s good for updates, but for removals it’s the opposite of what we want. If you remove a dependency first, any remaining dependents still in the set will fail to compile, so the removal gets rejected even if those dependents are also slated for removal later.

Example:

• Change set removes foo and bar, where bar depends on foo.
• Order is foo then bar.
• Removing foo first makes bar not compilable -> removal of foo fails.
• Then bar removal runs, but foo never got removed.

So for removals, we want dependents removed before their dependencies, i.e., reverse topological order, if using upgradeSequential.