Upgrading the CLI from v50 to v51

Upgrading a self-run sfp-pro pipeline from v50 to v51 — bump the image, rename the handful of moved commands, and rework review-environment calls against sfp server.

v51 is the release where sfp gains a server: from v51 the CLI runs against sfp server and is no longer standalone. If your pipeline runs sfp itself — a container: image: …/sfp-pro:… job in GitHub Actions, Azure Pipelines, Buildkite, or any CI — this page covers the mechanical upgrade: the image, the moved commands, and the reworked review-environment calls.

Moving those workflows onto codev entirely — so the server runs them and there is no image or command for you to maintain — is a separate, gradual path; see Migrating to codev. The steps below apply to any sfp calls you still run yourself during or after that move.

Step 1 — Update the image

Point the version tag your pipeline pulls at a v51 release.

# Before (v50)
container:
  image: source.flxbl.io/flxbl/sfp-pro:50.x

# After (v51)
container:
  image: source.flxbl.io/flxbl/sfp-pro:51.x

If you mirror the image into your own registry, sync the v51 tag first — see Automated Image Synchronization to Your Registry. Valid version tags are listed at https://source.flxbl.io/flxbl/-/packages/container/sfp-pro/.

What comes with the new image:

Component	v50	v51
Base OS	Debian bookworm	Debian trixie
Salesforce CLI	2.131.7	2.135.7
JDK	17	21
Data-move runtime (sfdmu)	installed as an sf plugin	bundled in the image, invoked in-process

You no longer install sfdmu yourself. On v50 the image ran sf plugins:install sfdmu; on v51 the data-move runtime ships inside the image and sfp calls it directly — remove any sf plugins:install sfdmu step from custom images. If you extend the sfp-pro base image with your own apt-get install layer, note that the trixie transition renames some system packages (the t64 suffix, e.g. libasound2 → libasound2t64).

Step 2 — Rename the moved commands

Most v50 commands run unchanged on v51. Commands that moved under a parent topic keep a backward-compatible alias, so existing invocations still resolve. The one exception is releasedefinition:generate: it moved under sfp server with no alias, so update it wherever your pipeline calls it.

# Before (v50)
sfp releasedefinition:generate -c HEAD -d release-definitions -f release-configs/my-release.yml -n $RELEASE_NAME -b $RELEASE_BRANCH

# After (v51)
sfp server releasedefinition generate -c HEAD -d release-definitions -f release-configs/my-release.yml -n $RELEASE_NAME -b $RELEASE_BRANCH

Moved but still work via aliases (update at your own pace):

v50	v51 canonical	Old form still works?
sfp dependency install	sfp org dependency install	Yes (alias)
sfp pool prepare	sfp server pool scratch init	Yes (alias)
sfp reviewenv fetch / transition	sfp server review-envs assign / acquire / release	No — reworked, see Step 3

Commands that did not move: sfp build, sfp install, sfp publish, sfp release, sfp pool delete, sfp validate pool. Your existing flags on these are unchanged.

A few v50 topics were removed entirely because the server owns them now (ai, config, resource, and the top-level releasedefinition). If your pipeline manually queued environment locks with sfp resource enqueue / wait / dequeue, that is replaced in Step 3.

Step 3 — Rework review-environment calls

This is the largest change for pipelines that run PR validation. On v50, fetching a review org, holding an exclusive lock, and returning it were separate CLI calls. On v51 the server manages the lease, and the CLI reserves and acquires in two phases.

# Before (v50) — one fetch, one status flip to return it
sfp reviewenv fetch --repository "$REPO" --issue "$PR" --pool "$POOL" --pooltype "$TYPE" --leasefor 60
# ... run validation ...
sfp reviewenv transition --repository "$REPO" --issue "$PR" --status "Available"

# After (v51) — reserve, then acquire exclusive access; release when done
sfp server review-envs assign  --type pr --id "$PR" --repository "$REPO" --pool-tag "$POOL_TAG" --domain "$DOMAIN" --expiration 60 --json
sfp server review-envs acquire --type pr --id "$PR" --repository "$REPO" --domain "$DOMAIN" --duration 90 --wait --poll-interval 30 --json
# ... run validation ...
sfp server review-envs release --type pr --id "$PR" --repository "$REPO"

Two related simplifications come with this:

• Pool-type probing is gone. v50 ran sfp pool probe to discover a pool's type before fetching. v51 carries the pool by tag, so that step is removed.
• Environment locking is a single action. The manual sfp resource enqueue / wait / dequeue sequence is replaced by one lock-and-authenticate step.

Step 4 — Verify

Confirm the CLI is on v51:

$ sfp --version
@flxbl-io/sfp-pro/51.23.0 darwin-arm64 node-v26.4.0

From here, each capability you hand to the server — build-on-merge, validation, pools — retires its CLI step from your pipeline. Migrating to codev walks that handover.

sfp versioning and upgrade Process