(e.g., Please formally support drop-in mongod binary build image replacement of [say] 3.0, 3.2, 3.4, 3.8 with a future version 4.0).

Some MongoDB versions have multi-step upgrade paths where one or more intermediate upgrade step(s) is(are) necessary, such as 2.6.3 -> 2.6.12 (latest available patch) -> 3.0.x -> 3.2.x.

The requested feature, if, for example, it had been available in 3.2.x, would have permitted the single-step, direct upgrade of 2.6.3 -> 3.2.x.

Customer Value

Configuration change-controls surround high-value big database assets. A customer's introduction of a new MongoDB build binary triggers formal change control testing and gate-keeping requirements in many applications. Enabling formally-supported single-step "long" upgrade paths maximizes the efficiency of such customer investments.

The requested feature's customer value effectively:

(a) spares operating time and budget by cutting the cost of re-qualifying / re-certifying the MongoDB binaries and post-upgrade database for each upgrade path step - as formal change control typically require, and

(b) "buys time" by deferring the must-upgrade path time horizon's approach, extending the post-EOL support "last chance" opportunity to upgrade MongoDB.

This efficiency gain is amplified by the non-linear risk-mitigating costs of data at increasing scales, availabilities and reliability, core strengths of MongoDB. It is therefore a potential strategic product priority to the largest customers that MongoDB binaries can operate stably upon well-formed (and perhaps auto-repair malformed) ancestor-versioned database metadata, over a time horizon compatible with the budgets and infrastructure upgrade cadence of large data asset holders.

Second Possible Example Feature Behavior

Not intended as design guidance, but to convey the customer's value perspective. Say a (future) MongoDB 4.0 binary is swapped-in for a MongoDB 3.0/3.2/3.4 binary that was gracefully shutdown in a known good state, the expectation is that the new 4.0 binary starts up, joins the cluster and operates normally. 'Stepping-up' compatibility levels - upgrading/rebuilding database file structures and enabling new features - may be DBA-directed, or self-coordinated by a critical quorum of 4.0 nodes, or automation-directed under Atlas/Cloud/Ops Manager, etc., but proceeds without intervening-version binaries having to be dropped-in and re-started which can trigger formal (expensive, time-consuming) data, performance and applications re-qualifications.