Linux 核心版本史教你讀發布邏輯

我把 Linux 核心版本史拆成一份可直接套用的發布政策模板。

我看 Linux kernel 版本史看了好一陣子，越看越火大。大家老愛把它講成「版本越大，變化越大」的直線故事，彷彿 6.x、7.x 一換，整個核心就翻桌重寫。實際上完全不是這樣。數字只是標記，真正重要的是支援窗口、維護節奏、還有這個版本到底是在告訴你「能不能上」還是「能撐多久」。我最受不了的是，很多團隊自己也在做版本號，卻把版本號當成面子工程，最後讓使用者自己猜政策。

我後來才明白，Linux 的版本史之所以值得學，不是因為它很熱鬧，而是因為它把「怎麼發、怎麼維護、怎麼讓人判斷風險」這三件事綁在一起。這比一堆花俏 release note 有用多了。你如果也在做 SDK、平台、服務或內部基礎設施，我覺得這套思路真的可以直接抄。

我這篇的起點是 Wikipedia 的 Linux kernel version history，我拿它當骨架，再去對照 kernel.org、Linux Foundation，以及 Civil Infrastructure Platform 的支援脈絡。這不是新聞整理，我是把它拆成你可以拿去改自己發布頁的做法。

版本號不是風險等級，別自己腦補

Linux kernel 的 major version 並沒有像一般語意化版本那樣，天然代表破壞性或重大升級；它更像一條 release line 的標記。

白話講就是：Linux 核心的數字，不是在跟你說「這版很危險」或「這版很小」。它只是告訴你這是一條哪個分支的發布線。很多人看到 6.x 跳到 7.x，就先腦補成大改版，然後在會議上開始瞎緊張。這種讀法很常見，但真的很蠢。

我以前在平台團隊也踩過類似坑。有人看到 major bump 就以為一定有 API 地震，結果文件、測試、上線流程全部被帶歪。後來才發現，真正該問的不是「數字大不大」，而是「這條線對相容性、支援期、回補策略的承諾是什麼」。Linux 早就把這件事講得很清楚，只是很多人懶得聽。

實操寫法很簡單：你自己的版本號要先定義語義。它到底是 release train、相容性承諾、還是純粹行銷標籤？三選一先講清楚，別混著用。

• 版本號只負責辨識發布線，不負責替你背書風險。
• 相容性承諾要另外寫，不要藏在數字裡。
• 如果使用者會拿版本號猜安全性，你的命名規則就有問題。

支援窗口比版本名更值錢

Linux 版本史真正有用的地方，不是新版叫什麼，而是每條線到底支援多久。Wikipedia 這頁把版本分成幾種支援型態：跟著下一版穩定版走、長期支援版，以及由 CIP 維護的超長期支援。這才是實際營運會看的東西。

也就是說，你如果在管基礎設施，重點根本不是 6.18 還是 6.19，而是你能不能安心撐到明年、後年，甚至更久。很多團隊很愛發新版，卻不敢講支援到哪一天。結果半年後大家才發現，自己 pin 的 branch 已經沒人修了。這種事我看太多次了，真的很煩。

我之前幫團隊選過要跟 distro kernel 還是更貼 upstream。最後不是 feature 表贏了，而是支援政策贏了。因為你一旦把問題換成「多久能拿到修補」而不是「有什麼新東西」，答案就會變得很現實。

實操寫法：把支援窗口直接寫在版本頁上，不要只寫 release date。使用者可以接受慢一點，但不能接受你講不清楚。

• 版本名旁邊直接放 support end date。
• 把 latest stable、LTS、SLTS 分開列。
• 先講維護多久，再講功能多炫。

3.x 的改名，不是技術重寫，是在修正誤讀

Wikipedia 提到，從 3.x 開始，minor version 被刻意壓在 20 左右，目的不是技術限制，而是避免大家誤以為大數字變化代表更小的改動。這種做法很老實：既然版本號會誤導人，那就把容易誤導的地方修掉。

翻譯一下就是，Linux 團隊早就知道版本號本身會製造錯覺。你如果讓 3.1 到 3.2 看起來像大改，讓 3.30 到 3.31 看起來像小改，那使用者讀版本的方式就會反過來。這不是技術問題，是溝通問題。

我很喜歡這個決策，因為它承認一件很多工程團隊不想承認的事：版本號是溝通工具，不是帳務系統。你如果讓它誤導使用者，那就是設計失敗，不是使用者太笨。

實操寫法：檢查你自己的版本規則有沒有在暗示不存在的風險或規模差異。如果有，就調整命名、補文件，必要時直接重設版本策略。

• 別讓數字大小暗示改動大小。
• 如果版本號會誤導，就改規則，不要只改簡報。
• 把相容性說明放在版本頁主體，不要藏 FAQ。

功能列表其實是在透露維護重心

Linux kernel 的 release history 裡，每條線都會列出一堆功能：像是 fsnotify、io_uring、Clang capability analysis、新 syscall、檔案系統與排程調整。表面上看起來像「這版加了什麼酷東西」，但我覺得那是最淺的讀法。

更準確的讀法是：這些功能在告訴你，維護者把力氣花在哪些地方。某個版本一直在補檔案系統，代表那塊還在收斂；某個版本在補 async I/O，代表那條 API 還在磨；某個版本新增 syscall，代表行為正在被正式化。這些都不是單純功能清單，而是維護方向。

我之前看某個平台 release note 也是一樣，大家只會寫「新增某某功能」，但完全沒說這是穩定化、效能、清理、還是安全硬化。結果使用者根本無法判斷這個版本該不該上。Linux 的做法比較乾脆：功能就是信號，信號要能讀。

實操寫法：每個變更都標分類，不要只列名稱。你要讓讀者一眼看出這次是在做什麼。

• 把變更分成 API 穩定、效能、安全、清理、相容性。
• 移除項目要獨立列，不要混在新增裡。
• 同一子系統反覆被改，通常代表設計還沒站穩。

真正的產品是長支援分支，不是首頁上的最新號

Linux 版本史最有意思的地方，是它同時照顧多種時間尺度。mainline 在跑，stable 在撐，LTS 和 SLTS 則是很多實際系統真正依賴的生命線。你如果只看最新版本，會錯過整個專案最像產品的那一面。

像 Debian、RHEL、Ubuntu、嵌入式系統、各種基礎設施，很多時候要的不是最新，而是「我可以放心撐三年、五年、甚至更久」。這跟一般 app 的節奏完全不同。最新版本很爽，但不一定適合上線；能長期維護的分支，才是大家真的拿來活的東西。

我碰過不少團隊一直迷信 latest，覺得新就是好。結果一碰到 driver、認證、供應商支援，整個方案就卡死。你如果部署情境需要穩定，那你要找的是支援故事，不是版本號本身。

實操寫法：至少拆兩條線，一條快、一條穩。快線給開發跟試驗，穩線給真正要活下去的使用者。

• 快線負責新功能驗證。
• 穩線負責可預期的維護。
• 如果你只有一條線，就老實說明你要大家承擔你的節奏。

版本史其實是維護史，不是發表會

我讀到最後，得到的結論很直接：Linux kernel version history 不是在展示「每版多厲害」，而是在展示「這個專案怎麼被照顧」。維護者、支援日期、支援類型、功能主題，這些東西放在一起，才構成真正有用的版本史。

Linux 核心從 1991 年一路長到現在，0.11 時期就已經能 self-host，1.0.0 在 1994 年出現，當時已經有超過 170,000 行原始碼。這些數字不是拿來炫耀的，是在說：一個大型專案可以長大，但不能失去自己定義發布節奏的能力。

我最想偷學的是這個結構，不是它的程式碼。版本頁如果只是在列 changelog，那只是讓維護者看起來很忙；如果它能讓使用者判斷能不能上、能撐多久、誰在維護，那才是真的有用。

實操寫法：你的版本頁要直接回答三件事：誰維護、維護多久、這條線主要在做什麼。少一個，使用者就得自己猜。

可抄的模板

# Release history template inspired by Linux kernel version history

## What this page is for
This release history documents version lines, maintenance windows, and the kind of change each line is expected to carry.

## Versioning policy
- Major version: identifies a release line, not a compatibility promise by itself.
- Minor version: used for release sequencing within a line.
- Patch version: used for fixes and backports.
- Version numbers do not replace compatibility documentation.

## Support levels
- Latest stable: maintained until the next stable release plus a defined grace period.
- LTS: maintained for a multi-year window.
- SLTS: maintained for extended infrastructure use cases.

## Release table
| Version | Release date | Maintainer | Support end | Status | Main themes |
|---|---:|---|---:|---|---|
| X.Y | YYYY-MM-DD | Name or team | YYYY-MM-DD | Stable / LTS / SLTS | Short list of theme areas |
| X.Y.Z | YYYY-MM-DD | Name or team | YYYY-MM-DD | Patch line | Fixes, backports, security updates |

## How to read this page
- If you need the newest features, use the latest stable line.
- If you need predictable maintenance, use LTS.
- If you need long infrastructure support, use SLTS.
- Do not infer risk from the size of the number alone.

## Release note format
### Version X.Y
- Release date:
- Maintainer:
- Support window:
- Notable additions:
- Notable removals:
- Compatibility notes:
- Operational notes:

## Example feature tagging
- API stabilization
- Performance
- Security hardening
- Cleanup / removal
- Hardware support
- Filesystem / storage
- Scheduling / runtime behavior

## Example deprecation policy
- Announce deprecations at least one release line before removal.
- Document replacement paths.
- Keep removal notes visible in the release table.

## Example support statement
This release line is supported until the next stable line plus 3 months.
LTS lines are maintained for multiple years.
SLTS lines are maintained for infrastructure deployments that need longer horizons.

## Copy this into your own project
Replace the placeholders with your own version lines, support dates, and maintainer names.
Keep the policy visible on the same page as the history.

這段模板是我根據 Wikipedia 的 Linux kernel version history 重寫出來的，不是原文照抄。原始事實脈絡來自那頁，延伸的整理方式則是我自己整理成比較適合工程團隊直接用的格式。

如果你要查原始資料，我會先看 Wikipedia，再對照 kernel.org 的發布資訊，補上 Linux Foundation 與 CIP 的支援脈絡。這幾個來源加起來，夠你把自己的 release policy 寫得像回事。