所有的 Kotlin 相關的框架或是套件都有著相同的一套 stability 評斷的標準，可以讓開發者能夠快速的了解目前專案的成熟度以及穩定性，這對於要在公司內部使用也是個非常重要的指標，而 Kotin 的 stability level 總共有以下幾級：

• Experimental
  
  通常是一個新功能或工具剛推出的實驗階段，依據實驗的結果是有可能臨時就被砍掉的，建議只在測試專案中使用。
• Alpha
  
  表示這個功能或工具通過了實驗階段，Kotlin 將會投入資源來長期支援並開發，但屬於早期階段，內部還有很多東西會調整，也不保證之後的 migration 複雜度。
• Beta
  
  表示這個新功能或工具已經具有一定成熟度，Kotlin 團隊會盡可能降低之後的 migration 成本。
• Stable
  
  我想這個就很清楚了，表示已經足夠成熟穩定，可以在最保守複雜的環境下使用也沒問題。

各個 level 間並沒有明確的時間表多久就可以進入到下個階段，也不意味著在正式 release 前會有多少的改變，主要的用意還是在於讓使用者知道目前的成熟度以及 migration 可能的風險指數。

為什麼我們要提這個呢？其實 KMM 是在 2020 年的九月隨著 Kotlin 1.4 的 release 就已經進入到 alpha 階段了，雖然說沒有規定每個階段的時間該停留多久，但現在已經 2022 年的九月了，KMM 還是在 alpha，是什麼原因讓 KMM 無法邁向 beta 呢？其中一個最大的原因就是 KMM 想在 beta 時在 Kotlin/Native 這塊使用新的 memory manager，讓 native 的使用更簡單直覺。

What’s the new Memory Manager

藉由之前的介紹，相信大家理解了 KMM 其實是透過不同的 compiler 把同一份 Kotlin code 轉成不同平台/語言能支援的格式的，所以通常我們不需要處理不同語言間的差異，但因為這些 compiler 的不同，比如說不同的 gc 方法，有時候也會造成寫法上的差異。

這些差異存在著一些歷史因素，大家都知道 Kotlin 是 100% 相容於 Java 的，而 Kotlin/Native 從 2016 設計之初時也想要 100 % 支援 Objective-C，所以它們的 GC 跟 Objective-C 一樣是 reference count 的，但 Objective-C 是需要一些輔助的程式來主動管理 memory 保持高效能的。但這個設計跟 Kotlin 希望作為一門簡單易學的通用語言相違背，所以 Kotlin/Native 並不需要增加這方面的負擔，但同時也帶來了一些限制，比如只有 immutable 的物件可以在不同的 thread 裏面共用等。而新的 memory manager 就是為了讓這邊的使用可以更自由。

When will it be Beta?

Kotlin 在各個管道都蠻一致的提到 KMM 將會在 2022 年的秋季進入 beta，我相信如果沒什麼意外的話應該也就是這一個月的事情了，但另外我想提的是就算目前還在 alpha，已經有蠻多知名的公司開始在使用，比如 Jake Wharton 所在的 cash app、百度、Netflix 等，可以看得出來一定是利大於弊才會驅使這些公司即使是 alpha 階段也願意嘗試，雖然我並不建議初學者現在就把公司的程式碼改成 KMM，但找個 side project 開始玩玩看，相信你也會很快感受到他的魅力。

Reference

https://kotlinlang.org/docs/components-stability.html#stability-levels-explained