Phiên bản Ruby của bạn có còn được hỗ trợ? Hướng dẫn về vòng đời phát hành từ người bảo trì

Tôi là Hiroshi Shibata (hsbt), một Ruby committer và một trong những người bảo trì nhánh chịu trách nhiệm về các bản phát hành ổn định của Ruby. Tôi cũng đồng thời bảo trì RubyGems và Bundler.

Tóm tắt nhanh

Kể từ các bản phát hành bảo mật vào tháng 3 năm 2026 cho Ruby 3.3.11 và 3.2.11, không có vấn đề xây dựng (build) nghiêm trọng hay lỗi nào khác được báo cáo. Như đã thông báo trong từng ghi chú phát hành, tôi xin xác nhận: Ruby 3.2 đã đạt đến cuối vòng đời (End-of-Life), và Ruby 3.3 đã chuyển sang chế độ bảo trì chỉ tập trung vào bảo mật.

Nếu bạn đang sử dụng một trong hai phiên bản này, bây giờ là thời điểm để lên kế hoạch nâng cấp lên Ruby 3.4 hoặc 4.0. Bài viết này sẽ giải thích cách hoạt động của chu kỳ phát hành Ruby, ai bảo trì từng nhánh, và "bảo trì bảo mật" thực sự có ý nghĩa gì trong thực tế.

Những gì đã xảy ra vào tháng 3

Vào ngày 26-27 tháng 3 năm 2026, chúng tôi đã phát hành Ruby 3.3.11 và 3.2.11 — cả hai đều khắc phục lỗ hổng bảo mật CVE-2026-27820, một lỗi tràn bộ đệm trong Zlib::GzipReader. Đây không phải là các bản vá thông thường:

• Ruby 3.2.11 là bản phát hành cuối cùng của dòng 3.2. Sẽ không còn bất kỳ bản cập nhật nào nữa. Ruby 3.2 đã được hỗ trợ trong hơn ba năm kể từ khi phát hành lần đầu vào ngày 25 tháng 12 năm 2022.
• Ruby 3.3.11 là bản phát hành bảo trì bình thường cuối cùng của dòng 3.3. Từ bây giờ, Ruby 3.3 sẽ bước vào giai đoạn bảo trì chỉ tập trung vào bảo mật trong một năm, cho đến tháng 3 năm 2027.

Sự chuyển đổi trạng thái này diễn ra vào mỗi mùa xuân, khoảng ba đến bốn tháng sau khi bản phát hành Ruby mới ra mắt vào dịp Giáng sinh. Nếu bạn đã sử dụng Ruby một thời gian, quy luật này có vẻ quen thuộc. Tuy nhiên, chi tiết về cách vận hành của nó chưa được tài liệu hóa rộng rãi bằng tiếng Anh, vì vậy đây là bức tranh toàn cảnh.

Quy trình phiên bản của Ruby: Không hoàn toàn là Semver

Ruby tuân theo sơ đồ MAJOR.MINOR.TEENY trông giống như phiên bản hóa ngữ nghĩa (Semantic Versioning) nhưng thực tế không hoàn toàn như vậy:

• MAJOR tăng khi Matz quyết định thời điểm thích hợp. Không có tiêu chí hay lịch trình xác định trước — hoàn toàn phụ thuộc vào quyết định của ông. Sự nhảy vọt từ 2.x lên 3.0 diễn ra khi Ruby 3x3 (hiệu suất gấp 3 lần), Ractor (tính toán song song) và RBS (chữ ký kiểu dữ liệu) hoàn thiện. Sự nhảy vọt lên 4.0 mang theo ZJIT (trình biên dịch JIT thế hệ tiếp theo), Ruby Box (cô lập định nghĩa) và các cải tiến Ractor. Cả hai lần tăng phiên bản lớn đều phản ánh nhận định của Matz rằng các thay đổi tích lũy xứng đáng với một phiên bản chính mới.
• MINOR tăng vào mỗi dịp Giáng sinh. Mỗi ngày 25 tháng 12, một phiên bản ổn định mới được tung ra. Các thay đổi không tương thích API có thể và thường xuất hiện trong các bản phát hành MINOR — ví dụ, các thư viện chuyển từ default gems sang bundled gems, nghĩa là bạn cần thêm chúng vào Gemfile một cách rõ ràng. Điều này khiến nhiều người ngạc nhiên khi đến từ các hệ sinh thái tuân thủ Semver nghiêm ngặt.
• TEENY tăng cho các bản sửa lỗi và vá bảo mật, được phát hành mỗi hai đến ba tháng. Các bản phát hành TEENY duy trì tính tương thích của API. Con số này có thể lớn hơn 9 — Ruby 3.2 đã đạt đến 3.2.11.

Nhịp độ phát hành vào dịp Giáng sinh là một trong những đặc điểm riêng của Ruby. Điều này có nghĩa là mỗi năm, sẽ có một thời điểm dự đoán được khi phiên bản mới xuất hiện và cửa sổ bảo trì sẽ dịch chuyển.

Vòng đời của các nhánh phát triển

Ruby không có các phiên bản LTS (Hỗ trợ dài hạn). Thay vào đó, mọi nhánh ổn định đều trải qua cùng một vòng đời:

1. Bảo trì bình thường — nhận các bản sửa lỗi và sửa lỗi bảo mật. Kéo dài khoảng hai năm.
2. Bảo trì bảo mật — chỉ nhận các bản sửa lỗi bảo mật và sửa lỗi xây dựng nghiêm trọng. Kéo dài khoảng một năm.
3. Hết hạn sử dụng (End of life) — không còn bản phát hành nào nữa.

Một nhánh ổn định thường tồn tại tổng cộng khoảng ba năm. Tại bất kỳ thời điểm nào, chúng tôi bảo trì đồng thời ba hoặc bốn nhánh.

Dưới đây là trạng thái hiện tại tính đến tháng 4 năm 2026:

Phiên bản	Trạng thái	Người bảo trì nhánh	Ghi chú
Ruby 4.0	Bảo trì bình thường	k0kubun	Phát hành 2025-12-25
Ruby 3.4	Bảo trì bình thường	nagachika	Phát hành 2024-12-25
Ruby 3.3	Bảo trì bảo mật	hsbt	Phát hành 2023-12-25
Ruby 3.2	Hết hạn sử dụng (EOL)	hsbt	Phát hành 2022-12-25

Và đây là cách sự chuyển đổi diễn ra mỗi năm:

25 tháng 12: Phiên bản ổn định mới được phát hành (ví dụ: 3.4.0)
  → 4 nhánh được bảo trì trong khoảng 3 tháng

Tháng 3-4: Nhánh cũ nhất đạt đến EOL
  → Quay lại 3 nhánh
  → Nhánh cũ thứ hai chuyển sang bảo trì bảo mật

25 tháng 12: Phiên bản ổn định tiếp theo được phát hành
  → Chu kỳ lặp lại

Để thấy cụ thể điều này diễn ra như thế nào: vào tháng 3 năm 2025, Ruby 3.1 đã hết hạn sử dụng với bản phát hành cuối cùng 3.1.7, và Ruby 3.2 chuyển từ bảo trì bình thường sang bảo trì chỉ bảo mật. Một năm sau, vào tháng 3 năm 2026, điều tương tự xảy ra với phiên bản tiếp theo — Ruby 3.2 hết hạn sử dụng và Ruby 3.3 bước vào bảo trì bảo mật. Nếu quy luật này giữ nguyên, Ruby 3.3 sẽ hết hạn sử dụng vào tháng 3 năm 2027 khi Ruby 3.4 chuyển sang bảo trì bảo mật.

Ai bảo trì cái gì

Việc bảo trì các nhánh của Ruby không phải là nỗ lực của một cá nhân, nhưng cũng không phải là một đội ngũ lớn. Hiện tại, bốn người đang xử lý tất cả các bản phát hành ổn định:

• nurse (naruse) — bảo trì nhánh phát triển (master) và xử lý bản phát hành Giáng sinh của mỗi phiên bản ổn định mới.
• k0kubun — bảo trì phiên bản ổn định mới nhất (hiện tại là Ruby 4.0). Phát hành mỗi hai đến ba tháng, đôi khi nhanh hơn khi cần thiết.
• nagachika — bảo trì Ruby 3.4 (bảo trì bình thường).
• hsbt (tôi) — bảo trì các phiên bản trong giai đoạn bảo trì bảo mật (hiện tại là Ruby 3.3) và xử lý các nhánh cho đến khi EOL (Ruby 3.2, hiện đã kết thúc). Cũng chịu trách nhiệm về cơ sở hạ tầng phát hành và tự động hóa.

Cấu trúc này được chính thức hóa thông qua một đề xuất vào năm 2024 để đơn giản hóa quy trình làm việc teeny release. Trước đó, việc phân công người bảo trì nhánh ít mang tính hệ thống hơn.

Đôi khi tôi mô tả vai trò điều phối của mình là "người quản lý các quản lý phát hành" — tôi không chỉ phát hành các nhánh của riêng mình, mà còn chuẩn bị mẫu cho thông báo phát hành, đảm bảo việc xuất bản CDN hoạt động, xóa bộ nhớ đệm tiêu cực và tự động hóa quy trình càng nhiều càng tốt để những người bảo trì nhánh khác có thể xuất bản bản phát hành với ít ma sát nhất.

Ý nghĩa thực tế của "Bảo trì bảo mật"

Thuật ngữ "bảo trì bảo mật" gợi ý rằng chúng tôi chỉ sửa các CVE trong giai đoạn này. Trong thực tế, phạm vi rộng hơn một chút:

• Sửa lỗi bảo mật — bất kỳ lỗ hổng nào được gán CVE sẽ được vá.
• Sửa lỗi xây dựng nghiêm trọng — nếu một hệ điều hành được hỗ trợ phát hành phiên bản mới và Ruby không thể xây dựng trên đó, lỗi đó sẽ được sửa. Phần mềm sẽ bị hỏng nếu để nó một mình; việc giữ cho Ruby có thể xây dựng trên các nền tảng hiện tại là một phần của công việc.
• Sửa lỗi kiểm thử — nếu các nền tảng CI mà chúng tôi kiểm thử gây ra lỗi kiểm thử, chúng tôi sẽ sửa mã kiểm thử để giữ cho bộ kiểm thử hoạt động tốt. Điều này làm giảm rào cản cho các bản phát hành khẩn cấp trong tương lai.

Mục tiêu rất đơn giản: nếu bạn đang chạy Ruby 3.3 trong môi trường sản xuất trong năm tới, nó nên tiếp tục được xây dựng và chạy trên các nền tảng bạn thực sự sử dụng. Chúng tôi sẽ không thêm tính năng hay sửa các lỗi nhỏ, nhưng chúng tôi cũng sẽ không để nó bị lỗi thời.

Nếu bạn phát hiện ra lỗ hổng bảo mật trong Ruby, vui lòng báo cáo qua HackerOne. Đối với các bundled gems, bạn cũng có thể sử dụng tính năng báo cáo lỗ hổng riêng tư của GitHub trên kho lưu trữ của gem đó. Chúng tôi đã dần chuyển sang GitHub cho các bundled gems vì nó cho phép những người bảo trì của từng gem xử lý quy trình trực tiếp.

Cách một bản phát hành được thực hiện

Đối với một bản phát hành teeny bình thường, quy trình trông大致 như sau:

1. Các bản sửa lỗi được đưa vào master trước, sau đó được backport (chuyển ngược) sang các nhánh ổn định. Đối với phiên bản ổn định mới nhất, những người đóng góp tích cực phân loại và tạo bản vá, người bảo trì nhánh sẽ backport. Đối với các nhánh cũ hơn, tôi tự chọn các bản sửa lỗi thủ công.
2. Người bảo trì nhánh chạy CI trên tất cả các nền tảng được hỗ trợ và sửa mọi thứ bị hỏng.
3. Khi sẵn sàng, người bảo trì gắn thẻ (tag) bản phát hành. Từ thời điểm đó, tự động hóa sẽ tiếp quản — các gói phần mềm được xây dựng, kiểm thử và xuất bản.
4. Thông báo phát hành được đăng lên ruby-lang.org.

Nếu bạn tìm thấy một lỗi đã được sửa trên master nhưng chưa xuất hiện trong bản phát hành ổn định, bạn có thể yêu cầu backport. Quy trình được tài liệu hóa trên trang wiki How To Request Backport. Tóm lại: tạo một vé trên bugs.ruby-lang.org với mã băm của commit trong tiêu đề (ví dụ: "Backport abcde123"), và người bảo trì nhánh sẽ xử lý nó. Nói chung, chỉ các bản sửa lỗi mới đủ điều kiện để backport — việc thêm tính năng sẽ giữ lại trên master. Thậm chí tốt hơn, bạn có thể mở pull request trực tiếp đối với nhánh mục tiêu (ví dụ: ruby_3_4) trên GitHub. Điều này giúp tiết kiệm thời gian cho người bảo trì nhánh và đưa bản sửa lỗi của bạn vào bản phát hành tiếp theo nhanh hơn.

Điều này có ý nghĩa gì đối với bạn

Nếu bạn đang dùng Ruby 3.2: hãy nâng cấp ngay lập tức. Sẽ không còn bản phát hành nào nữa, thậm chí cả các vấn đề bảo mật.

Nếu bạn đang dùng Ruby 3.3: bạn có thời gian đến tháng 3 năm 2027, nhưng chỉ có các bản sửa lỗi bảo mật được backport. Hãy bắt đầu lên kế hoạch nâng cấp.

Nếu bạn đang dùng Ruby 3.4 hoặc 4.0: bạn đang ở vị trí tốt. Bảo trì bình thường vẫn tiếp tục.

Một ngoại lệ: nếu bạn đang sử dụng các gói Ruby do bản phân phối Linux như RHEL, Ubuntu hoặc Debian cung cấp, các ngày EOL thượng nguồn nêu trên không áp dụng trực tiếp với bạn. Những bản phân phối đó tự bảo trì các gói của mình và backport các bản sửa lỗi bảo mật theo chu kỳ hỗ trợ của riêng họ. Hãy kiểm tra tài liệu của bản phân phối để biết thời gian hỗ trợ thực tế của phiên bản Ruby bạn đang chạy.

Kiểm tra trang trạng thái nhánh chính thức để biết trạng thái bảo trì mới nhất: ruby-lang.org/en/downloads/branches/

Để biết chi tiết về những gì thay đổi trong mỗi phiên bản, tệp NEWS trong cây nguồn Ruby là tài liệu tham khảo chính xác. Nếu bạn muốn bắt các cảnh báo ngừng sử dụng trong ứng dụng của mình, hãy thử chạy với ruby -w để bật tất cả các cảnh bao gồm cả các cảnh báo ngừng sử dụng.

Ghi chú

• Được viết vào tháng 4 năm 2026. Trạng thái nhánh và phân công người bảo trì có thể thay đổi theo thời gian.
• Tôi là một Ruby committer và người bảo trì nhánh. Bài viết này phản ánh quan điểm của tôi về cách quy trình hoạt động trong thực tế.