invalid_replication_spec error when using legacy replication document with CouchDB 3.x

Administrators running mixed‑version CouchDB environments need to know whether a replication document created with the 2.x format will continue to be accepted by a 3.x cluster.

The current 3.x validator rejects legacy documents that use plain strings for source and target, returning the invalid_replication_spec error.

While the 2.x server tolerated both string and object forms, the 3.x schema introduced a stricter structure, and the project has not yet decided if future releases will retain support for the legacy format.

This uncertainty affects upgrade planning and replication reliability.

Should CouchDB 3.x retain backward compatibility for the legacy replication format in upcoming releases?

What impact would retaining or dropping support have on existing upgrade paths and data‑sync guarantees?

Are there recommended migration strategies that administrators can adopt now to avoid reliance on an undecided behavior?