PM2 cross-version upgrade risks dump resurrection failure

PM2's upgrade mechanism replaces the running daemon and attempts to restore processes from a saved dump file. When the installed PM2 version changes, the dump format and process metadata may become incompatible, causing pm2 resurrectcode to fail silently or partially. Boot-time resurrection via pm2 startupcode can also reference a stale PM2 binary path, requiring manual reconfiguration.

Because no built-in rollback command exists, teams must establish their own policies for version pinning and dump-file snapshotting across upgrade cycles.

Does pm2 resurrectcode reliably restore all processes when the installed PM2 version differs from the version that produced the dump? What is the recommended practice for snapshot frequency and retention of dump.pm2 across planned major-version upgrades? Can pm2 startupcode scripts be automatically updated to point at a newly installed PM2 binary, or must this be managed per environment?