Rust 的滾動式支援，才是團隊真正該接受的取捨

Rust 應維持滾動式支援，而不是改成 LTS 或多分支維護。

Rust 現在的支援週期，對多數團隊來說就是正解：只有最新穩定版拿得到修正，這不是缺陷，而是設計。

從 versionlog 的發布紀錄看，Rust 每 6 週就出一版 stable，前一版會在下一版上線後停止修補。到 2026 年 6 月 17 日，網站顯示 1.96.0 是最新穩定版，1.95 已結束支援。這套規則沒有隱藏保護傘，團隊必須把升級納入日常，而不是期待某個長壽分支替你承擔技術債。

第一個論點

滾動式支援會逼出更健康的升級習慣。Rust 固定 6 週一版，讓團隊不必等一年才看到新工具鏈改善，也不會把修補累積成一條越拖越長的債務鏈。編譯器修正、borrow checker 改良、標準函式庫更新都能快速進入 stable，而生產環境只需要追一條主線。這種節奏讓生態系統保持同步。

versionlog 的時間表很直接：Rust 1.95.0 在 2026 年 4 月 16 日發布，到了 5 月 28 日就停止支援，正好銜接 1.96.0。這種短窗口不是為了折磨使用者，而是為了建立紀律。若團隊把升級當例行工作，這節奏完全可控；若一直等「以後再升」，最後只會把依賴更新變成大型專案。

第二個論點

Rust 的 edition 機制，已經解掉大部分對 LTS 的需求。人們想要 LTS，通常是怕破壞相容性；但 Rust 目前支援 2015、2018、2021、2024 四個 edition，crate 可以在 Cargo.toml 中選擇 edition，同時繼續使用最新編譯器。也就是說，語言可以演進，來源碼相容性則被控制在 crate 邊界。

這也是 Rust 能比死守長期支援分支的語言更快前進的原因。團隊可以讓舊 crate 留在較老 edition，同時用最新 stable toolchain 編譯。語言演進與部署穩定被清楚分開。在其他生態裡，LTS 常常只是相容性設計不足的補丁；在 Rust 裡，edition 才是相容性設計本身。

反方可能怎麼說

反對聲音最強的一點，不是理念，而是營運。企業要的是可預測性：版本最好固定 12 到 24 個月，尤其是認證、嵌入式目標、法規環境會讓工具鏈頻繁變動的成本很高。資安團隊也會追問，編譯器能不能持續收到修正，而不是每 6 週就被迫升級語言。

這個擔憂是真實的。固定工具鏈更容易稽核，有些組織也確實會用 release train 來管理風險。只是把 Rust 改成 LTS，未必真的省事。crate 生態仍在快速前進，MSRV 也常變動，而且編譯器層級修正只回補給 current stable。長壽分支不會消除升級工作，只會把它延後，並拉大你的工具鏈與整個生態系之間的距離。

更務實的結論是接受這個限制：Rust 不是為拒絕計畫性維護的靜態環境而設計，它是為能按節奏升級的團隊設計的。這個取捨是刻意的，也正是它能在 compiler、tooling、package ecosystem 之間維持一致性的原因。

你能做什麼

如果你是工程師或技術主管，把 Rust 升級當成固定營運項目，而不是例外。追蹤最新 stable，設定最低支援 Rust 版本，並在每個 release cycle 預留時間測試新編譯器。如果你是創辦人或 PM，不要先要求 Rust LTS，先問產品能不能承受 6 週一次的升級節奏，因為這才是 Rust 支援模型真正要求你回答的問題。