Deterministic Byte Order Guarantees for Racket's serialize/write Across Releases

Direct answer

racket/serialize's write does not guarantee identical byte sequences for the same value across different Racket releases. The stream includes a format version field, and internal encoding details may evolve between major versions. The practical compatibility guarantee is narrower: a stream written by an earlier release should be readable by a later release, reconstructing an equal?-equivalent value for immutable data.

Confirmed behavior vs. likely explanation

Confirmed by the module's design and documentation:

• The serialized form carries a version identifier so read can select the appropriate parser.
• Mutable containers (vectors, hash tables, instances, etc.) are restored as fresh copies; their identity is not preserved, but their contents remain readable if the container type is still supported.
• No documented promise exists that two releases will emit byte-identical output for the same input.

A likely explanation for byte differences is that newer releases may introduce new type tags, change internal field ordering, or adopt more compact encodings. These changes can alter the byte stream while preserving the ability to read older data.

Version-specific constraints for backup and restore

1. Backward compatibility is the only safe direction. Treat a file written by a newer release as potentially unreadable by an older release. Do not assume forward compatibility.
2. Custom structs and module dependencies must match. If your data includes structs defined in your own modules, both the writer and reader need the same module definitions and compatible struct type descriptors. A missing or changed struct type can break readability even when the core format is compatible.
3. Mutable state is copied, not shared. When restoring a backup, expect fresh mutable objects. If your application relies on object identity across serialization boundaries, racket/serialize will not preserve it.
4. For long-term archival, pin the version. Either restrict both writing and reading to a single Racket release, or use a fixed, known serialization version if your Racket version provides version-specific writer functions. This removes ambiguity about which parser will be used years later.

Practical verification

Before relying on cross-release behavior, verify with the exact versions you plan to use. The following Racket snippet compares bytes across two installed interpreters and checks read-back equivalence:

#lang racket
(require racket/serialize)

(define val 42)

;; Run this in Racket version A, save bytes to a file:
(define outA (open-output-bytes))
(write val outA)
(define bytesA (get-output-bytes outA))

;; Run the same in version B, then compare:
(define outB (open-output-bytes))
(write val outB)
(define bytesB (get-output-bytes outB))

(displayln (byte=? bytesA bytesB)) ; expect #f if versions differ

;; Read A's bytes under B:
(define inA (open-input-bytes bytesA))
(define restored (read inA))
(displayln (equal? val restored)) ; expect #t for immutable data

If you need a definitive compatibility statement for a specific version pair, provide the exact releases; otherwise, the conservative recommendation is to avoid byte-level assumptions and pin your archival pipeline to one Racket version.