What’s new in P4 Server 2025.2

Released: November 2025

Learn about new features and enhancements in this release of P4 Server. For a complete list of what’s new in this release, including bug fixes, see the following resources:

• Release notes

• Developer notes for P4API, the P4 API for C/C++

• What’s new in P4 Virtual File Service (P4 VFS)

Introducing the P4 REST API

P4 2025.2 introduces the first version of the P4 REST API, giving developers a new way to automate workflows and integrate P4 with other tools.

This release includes the following endpoints:

• GET /api/version
• GET /api/v0/server/info
• GET /api/v0/depot
• GET /api/v0/file/metadata
• GET /api/v0/file/contents
• GET /api/v0/changelist/{changelistNumber}
• GET /api/v0/changelist/{changelistNumber}/files

To learn more about using the REST API, see the documentation.

The REST API runs on the new built-in P4 Web Server, which must be started before you can use the API. To learn more, see p4 webserver.

Stream syncing flexibility

• Reduce the amount of time it takes to sync a stream to your client workspace with LimitView filtering. You can now sync a subset of a stream to your client workspace without creating a virtual stream or issuing selective p4 sync commands. To learn more, see the LimitView: form field for the p4 client specification.

• You can opt out of the sync when merging from the parent stream to a sparse stream. To learn more, see the -v of p4 merge.

Ease of administration

• The ticket for a service user now defaults to unlimited, so it is no longer necessary to set the Timeout: field when creating a group for service users with the p4 group command.

• A change to the startup.N configurable no longer requires P4 Server to be restarted. To learn more, see the server.startup.autorestart and monitor configurables.

• Changes to the entries in the RevisionDataFilter field of the p4 server specification of a replica A P4 Server that automatically maintains a full or partial copy of the central server's metadata and that might contain related file content. The replica copies by using 'p4 pull' or 'p4 journalcopy'. A replica can be used as a backup server for disaster recovery. no longer require reseeding the replica or edge server. The replica-filter-reconcile subcommand of the p4 admin command provides a way to keep the downstream server in sync. To learn more, see p4 admin replica-filter-reconcile.

• For distributed versioning, a local server using unicode mode can run the p4 fetch command from a remote server using non-unicode mode. To learn more, see the new form field, RemoteCharset: , of the p4 remote spec.

Save space and time

• Save storage space with the new configurable, lbr.unloaddepot.compress, which, when enabled, writes unload depot A special depot for infrequently used metadata or to facilitate reloading workspaces that have been moved to a different server. in compressed mode.

• To avoid the delay incurred by calculating the digest during a P4 Server database upgrade, after the upgrade you can run the p4 storage command with the -U [-q] [-n threads] [--server-size-rcs]  option. This allows you to choose whether to calculate the serverSize field for RCS file types.

Extension enhancements

• If an extension needs to run commands against the server, the extension needs a P4 user account. To ensure the capability of running commands, by default, the require_user field is now set to true so that automatic logins of an extension require the existence of a valid user of the P4 Server. To learn more, see the require_user field under Server Extension JSON manifest fields in the P4 Server Administration Documentation.

• You can prevent users from creating multiple instance configurations of the same extension. To learn more, see the extension manifest limit_instance field in the P4 Server Administration Documentation.

Additional enhancements

• To help you work with Perforce Support, the p4 diagnostics command now produces an info file by default. This file contains the tagged output from p4 info and p4 servers -J as well as a list of the configurable settings that differ from the default values.

• To support customers with a large number of users issuing commands, the default value of db.monitor.shared increased from 256 to 1024.