comunes/todos-contra-el-fuego-web
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: confirm Mongo 3.2 ceiling = Meteor 2.5 (2.6 driver 4.x rejects wire v4)

Browse source 
Empirically verified: 2.4 and 2.5 green against mongo:3.2 (npm-mongo 3.9.1);
2.6 bumps npm-mongo to 4.3.1 which refuses MongoDB < 3.6
(MongoCompatibilityError, wire version 4). Branch lands on Meteor 2.5.
This commit is contained in:
vjrj 2026-07-13 22:40:40 +02:00
parent 208e250277
commit bddeca79a0
1 changed files with 30 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

43
UPGRADE.md
View file

@ -10,11 +10,13 @@ Production runs against the shared replica set **rsmain on MongoDB 3.2.11**.
Meteor 3 ships the modern `mongodb` Node driver, which requires a server
**≥ 4.2/4.4**. Meteor **2.x still works against Mongo 3.2**.
Therefore this branch stops at the **highest stable 2.x** with everything green,
and the `meteor update --release 3.x` step is **deliberately not taken** until
the Comunes infra team upgrades rsmain (shared infra — coordinated in a separate
phase, not unilaterally). The 2.x server code is migrated to async/await ahead
of time so the final 3.x jump is mechanical.
Therefore this branch lands on **Meteor 2.5** — empirically the highest release
whose bundled `mongodb` driver still connects to Mongo 3.2 (2.6 bumps the driver
to 4.x and fails; see "Escala ceiling" below) — with everything green. The
`meteor update --release 3.x` step (and even 2.6+) is **deliberately not taken**
until the Comunes infra team upgrades rsmain (shared infra — coordinated in a
separate phase, not unilaterally). Server code should still be migrated to
async/await before the final 3.x jump so it is mechanical (tracked as debt).
## ⚠️ Deploy-ordering dependency: notifications cutover
@ -155,15 +157,30 @@ historically). It was fully worked around by removing the dead build plugins
above. If a future escala hits it again, build in a container matching the
deploy target (Debian) rather than on this host.
## Escala ceiling vs Mongo 3.2
### Escalas 2.4 & 2.5 — ✅ green
Meteor bumps the bundled `mongodb` Node driver to **4.x at Meteor 2.5**, which
drops support for servers **< 3.6**. Production's rsmain is **Mongo 3.2**.
Therefore the highest Meteor that can talk to the current production DB is
**~2.4** (npm-mongo/driver 3.x). The smoke test runs against a real `mongo:3.2`,
so the exact ceiling is verified empirically: it stays green through 2.3;
2.5+ is expected to fail at connection time. **Landing target: highest 2.x that
keeps the smoke test green against Mongo 3.2.**
`meteor update --release 2.4`, then `--release 2.5`. Both trivial; `npm-mongo`
stays at **3.9.1** (mongodb driver 3.x). REST smoke byte-identical against
`mongo:3.2` on both.
## Escala ceiling vs Mongo 3.2 — **landing on Meteor 2.5** (empirically verified)
Meteor bumps the bundled `mongodb` Node driver to **4.3.1 at Meteor 2.6**, which
requires server wire version ≥ 6 (**MongoDB ≥ 3.6**). Production's rsmain is
**Mongo 3.2** (wire version 4). Verified directly by booting 2.6 against a real
`mongo:3.2`:
```
MongoCompatibilityError: Server at localhost:27018 reports maximum wire
version 4, but this version of the Node.js Driver requires at least 6
(MongoDB 3.6)
=> Exited with code: 1
```
So **Meteor 2.5 is the highest release that runs against the production Mongo
3.2** (npm-mongo 3.9.1). That is where this branch lands: everything green, REST
smoke byte-identical. Going past 2.5 (to 2.16 or 3.x) is gated on upgrading the
shared rsmain replica set to Mongo ≥ 4.4 first — the same DB blocker as 3.x.
## 🚧 3.x — blocked (do not run `meteor update --release 3.x`)