Đọc alpha, beta, RC, SemVer, LTS và EOL; phân biệt các lớp tương thích, dùng release notes và lập hồ sơ nâng cấp với ba thay đổi API giả định DEMO.
Một máy đang chạy ổn, trong khi trang tải xuống có bản số lớn hơn. Người dùng hỏi có nên cập nhật ngay không. Để trả lời, Help Desk cần biết nhánh hiện tại còn được hỗ trợ không, bản mới thay đổi gì, ứng dụng phụ thuộc có tương thích không và có cách phục hồi nào. Số phiên bản là đầu mối, chưa phải quyết định nâng cấp.
Bài 055.2, Quản lý sản phẩm và phát hành, tham chiếu Open Source Essentials 050-100 trang in 216–229, biên soạn độc lập và đối chiếu ngày 23/10/2026. Bạn cần hiểu phần mềm, API và quy trình kiểm thử cơ bản. Lab dùng ghi chú phát hành DEMO, không nâng cấp máy hoặc thay dữ liệu thật.
Kết quả cần đạt là phân biệt các loại bản phát hành, đọc quy ước phiên bản, tìm phạm vi hỗ trợ và lập hồ sơ thay đổi có điều kiện. Bài này mở rộng phần chuẩn bị kiểm chứng và phục hồi ở mức người mới, chưa triển khai hệ thống tự động phát hành.
Source được sửa liên tục, nhưng người dùng cần biết mình nhận bản nào. Một bản phát hành có thể gồm source, binary, package, tài liệu và ghi chú thay đổi. Các đầu ra cần liên hệ với phiên bản hoặc revision rõ ràng, thay vì chỉ mang tên “mới nhất”.
Release, deployment và đưa tính năng tới người dùng có thể là những bước khác nhau. Một package đã phát hành chưa chắc được cài trên hệ thống; một thay đổi đã triển khai có thể vẫn đang bị tắt bằng cấu hình. Trong ticket hỗ trợ, ghi bản đang chạy thực tế cùng nguồn xác nhận.
Không giả định mọi sản phẩm đều được cập nhật bằng một thao tác mạng. Thiết bị, ứng dụng desktop, cơ sở dữ liệu và dịch vụ có quy trình riêng. Quản lý phát hành phối hợp điều kiện sẵn sàng, lịch, tài liệu và người chịu trách nhiệm cho các đầu ra này.
Alpha thường chỉ giai đoạn thử nghiệm sớm; beta thường nhằm thu thêm phản hồi trên phần đã phát triển; release candidate, hay RC, là bản được đưa ra để đánh giá khả năng trở thành bản phát hành. Ý nghĩa chính xác phụ thuộc chính sách dự án. Không mặc định beta đã cố định mọi tính năng hoặc RC chắc chắn không còn lỗi.
Bản ổn định thể hiện mức cam kết mà dự án công bố, không phải chứng nhận không có lỗi hay lỗ hổng. Một bản ổn định vẫn cần được kiểm tra với hệ điều hành, plugin và dữ liệu mà tổ chức dùng. Tách môi trường thử nghiệm giúp thu bằng chứng mà không ảnh hưởng công việc thật.
Ví dụ DEMO: nhóm nhận bản ứng viên của công cụ ticket. Họ có thể kiểm tra định dạng xuất bằng dữ liệu giả, ghi lỗi và gửi theo hướng dẫn dự án. Kết quả tốt trên fixture đó chưa đủ để khẳng định nâng cấp production an toàn cho mọi dữ liệu.
Semantic Versioning 2.0.0 dựa trên public API được xác định. Với dự án tuân theo SemVer, MAJOR dành cho thay đổi API không tương thích; MINOR thêm chức năng tương thích; PATCH sửa lỗi tương thích. Nhãn prerelease và build metadata bổ sung thông tin. Giai đoạn 0.y.z chưa cam kết API ổn định; điều này không chứng minh mọi lần chuyển lên 1.0 đều chắc chắn phá tương thích.
Không áp SemVer cho mọi phần mềm có ba con số. Dự án có thể dùng ngày, lịch phát hành hoặc quy tắc khác. Số major mới cũng không nhất thiết phải đợi nhiều năm hoặc có giao diện thay đổi lớn. Đọc chính sách và release notes trước khi suy luận từ tên.
Trong công việc, hãy ghi cả chuỗi phiên bản đầy đủ. Bỏ hậu tố beta hoặc RC có thể làm người nhận hiểu nhầm loại bản. Hai gói cùng số nhưng khác kiến trúc, cấu hình build hoặc nguồn phân phối cũng cần được phân biệt khi điều tra lỗi.
Tương thích source API nói về cách mã gọi giao diện; ABI liên quan giao diện ở mức nhị phân. Khả năng chạy còn phụ thuộc kiến trúc CPU, hệ điều hành, thư viện và môi trường. Tương thích dữ liệu hoặc cấu hình lại là câu hỏi khác. Không dùng lời hứa API để kết luận một binary cũ chắc chắn chạy trên mọi phần cứng mới.
Một thay đổi có thể giữ tên trường nhưng đổi cách diễn giải, mặc định hoặc quyền truy cập. Đội IT cần xem hành vi người dùng và tích hợp thật sự phụ thuộc vào đâu. Với biểu mẫu hoặc báo cáo, kết quả so sánh phải bao gồm đầu ra, không chỉ việc ứng dụng mở được.
Khi tài liệu nêu một chức năng deprecated, hiểu rằng dự án đang cảnh báo hướng thay đổi theo chính sách của họ. Chưa thể suy ra nó đã bị xóa hoặc sẽ tồn tại mãi. Ghi thời hạn và phương án chuyển đổi nếu dự án công bố; tránh hứa thay cho bên bảo trì.
Roadmap thể hiện hướng đi dự kiến; milestone gom công việc hoặc mục tiêu. Ngày đích có thể thay đổi khi ưu tiên, nguồn lực hoặc rủi ro thay đổi. Một issue được gắn milestone chưa tự trở thành cam kết hợp đồng với mọi người dùng.
Lịch phát hành có thể thiên về thời gian, tính năng hoặc kết hợp cả hai. Khi gần ngày phát hành, feature freeze giới hạn việc thêm tính năng để tập trung ổn định theo chính sách dự án. Sửa lỗi bảo mật vẫn cần được đánh giá và xử lý; freeze không có nghĩa mọi thay đổi đều bị cấm.
Nếu một tính năng chưa sẵn sàng, nhóm có thể hoãn nó, thay phạm vi hoặc đổi lịch dựa trên tiêu chí đã xác định. Help Desk cần truyền đạt trạng thái từ nguồn chính thức thay vì lấy bình luận của một thành viên làm ngày phát hành chắc chắn.
LTS là hỗ trợ dài hạn nhưng thời gian, loại cập nhật, thành phần và điều kiện khác nhau. Canonical công bố chu kỳ hỗ trợ Ubuntu, trong đó có Ubuntu 26.04 LTS và các lựa chọn phạm vi bảo trì. Không suy ra mọi package hoặc mọi gói hỗ trợ có cùng thời hạn chỉ từ nhãn LTS.
Trang vòng đời Node.js tại ngày đối chiếu ghi Node 24 và 22 là LTS, Node 26 là Current, Node 20 là EOL. Ví dụ này cho thấy số lớn hơn chưa đồng nghĩa lựa chọn phù hợp hơn cho production; dự án khuyến nghị dùng Active LTS hoặc Maintenance LTS cho ứng dụng production.
EOL chỉ kết thúc phạm vi hỗ trợ được công bố cho nhánh đó. Phần mềm có thể vẫn chạy, nhưng việc sửa lỗi không còn theo cùng cam kết trước đây. Có source không tự tạo đội bảo trì hoặc bảo đảm tự backport được mọi bản vá. Kế hoạch chuyển nhánh nên bắt đầu trước thời hạn, gồm kiểm tra phụ thuộc và người tiếp nhận.
Changelog mô tả thay đổi; release notes có thể giải thích ảnh hưởng, vấn đề đã biết và cách nâng cấp. Hướng dẫn migration giúp xử lý thay đổi không tương thích. Tài liệu trực tuyến mặc định có thể dành cho bản mới, nên cần chọn đúng phiên bản trước khi sao chép lệnh hoặc cấu hình.
Hồ sơ nâng cấp tối thiểu ghi bản nguồn, bản đích, môi trường, phụ thuộc, bước kiểm tra, điều kiện dừng và cách phục hồi. Nếu thay đổi định dạng dữ liệu, hạ binary chưa chắc phục hồi dữ liệu được. Cần đọc điều kiện rollback và kiểm tra bản sao lưu theo quy trình phù hợp trước thao tác thật.
Các tài liệu này giúp người khác hiểu quyết định, nhất là khi người thực hiện vắng mặt. Không ghi thông tin xác thực vào ghi chú phát hành hoặc ticket công khai. Bằng chứng cần đủ để tái kiểm tra mà không lộ dữ liệu người dùng.
Giả định công cụ DEMO-Ticket công bố dùng SemVer và API tra cứu ticket đã được xác định. Bản hiện tại là 1.4.2. Tạo ba thẻ thay đổi: A sửa kết quả sai nhưng giữ hợp đồng API; B thêm bộ lọc tùy chọn tương thích; C xóa một trường mà client hiện dùng.
Đây là các giả định để học cách suy luận, không phải release notes của sản phẩm thật. Không tìm một package có tên giống rồi cài đặt. Bài tập chỉ cần một tệp ghi chú hoặc giấy.
Theo giả định, A phù hợp với bản vá, B với bản phụ, C cần xem như thay đổi không tương thích. Nếu từng thay đổi được phát hành độc lập từ 1.4.2, các nhãn dự kiến lần lượt là 1.4.3, 1.5.0 và 2.0.0. Không cộng tuần tự ba con số khi bài đã quy định các phương án độc lập.
Kết quả cần nêu lý do dựa trên API, không dựa trên số dòng code hoặc thời gian làm. Một sửa đổi rất nhỏ vẫn có thể phá tích hợp. Ngược lại, nhiều thay đổi bên trong chưa chắc yêu cầu tăng major nếu hợp đồng công khai được giữ.
Với A, ghi đầu vào tái hiện lỗi và kết quả đúng mong đợi. Với B, ghi truy vấn cũ vẫn chạy và truy vấn thêm bộ lọc trả đúng tập dữ liệu. Với C, ghi client nào cần sửa và hướng dẫn chuyển trường. Các mục này mới là kế hoạch, chưa phải kết quả chạy kiểm thử.
Thêm một kiểm tra cấu hình, quyền truy cập và dữ liệu xuất của tình huống văn phòng. Việc đọc đúng số phiên bản chưa kiểm tra các lớp đó. Nếu chưa đủ thông tin về bản đích, đánh dấu chờ thay vì tự xác nhận tương thích.
Giả định 2.0.0-rc.1 đã có artifact nhưng tài liệu migration chưa hoàn tất. Hồ sơ cần ghi đây là prerelease và thiếu tài liệu cho thay đổi C. Nhóm có thể tiếp tục đánh giá trong lab, chưa đủ căn cứ từ fixture này để quyết định thay production.
Bổ sung người chịu trách nhiệm tài liệu và tiêu chí kết thúc. Đường phục hồi phải xét dữ liệu, không chỉ lưu binary cũ. Bài thực hành kết thúc bằng quyết định có điều kiện cùng những bằng chứng còn cần thu thập.
Bản beta có chắc đủ toàn bộ tính năng bản cuối không? Không, cần xem chính sách dự án. Nhãn LTS có nghĩa mọi thành phần được hỗ trợ như nhau không? Không. Một bản vá có bảo đảm không phát sinh regression không? Quy ước phiên bản không thay kiểm chứng hành vi.
Nếu thấy tài liệu khác với bản đang chạy, xác nhận phiên bản và nguồn trước. Nếu nhánh đã EOL, lập phương án được đánh giá thay vì cho rằng source mở đồng nghĩa bảo trì miễn phí vô thời hạn. Nếu bản mới thay dữ liệu, yêu cầu kế hoạch phục hồi phù hợp trước thao tác.
Khung mục tiêu: LPI Open Source Essentials 055.2. SemVer, Canonical và Node.js được dẫn trực tiếp tại nội dung tương ứng. Trạng thái hỗ trợ có thể thay đổi, cần xác minh lại khi lập kế hoạch thực tế.
Chọn chat, email, issue, ticket và tài liệu theo mục tiêu; hiểu federation, wiki, CMS, DMS, rồi lập báo cáo, ghi chú quyết định và dàn ý tài liệu DEMO.
Phân biệt Git với nền tảng hosting, working tree, index, commit, branch và tag; thực hành nhánh, fast-forward, tag và revert trong repository riêng.
Phân biệt IDE, build, linter, debugger, các loại test và môi trường CI/CD; chạy lab Node để thấy cú pháp hợp lệ vẫn có thể sai hành vi rồi khôi phục.
Nhận diện maintainer, contributor, quản trị và tài trợ; đọc DCO, CLA, quy tắc ứng xử, rồi soạn phản hồi đóng góp tài liệu qua tình huống DEMO riêng.