Cách các framework và library tạo version (Semantic Versioning) 💖 💖💖

Chào mọi người, lại là Tiến đây 😆 Hôm nay chúng ta sẽ tìm hiểu về Semantic Versioning. Let’s get started 💖 💖
Bài viết gốc tại blog cá nhân của mình: https://tienvm.com/

1. Giới thiệu

• Khi xem change log ở các repo mã nguồn mở, mọi người có thể thấy các quy tắc tạo version khá linh tinh. Ví dụ đang ở 2.6.15 nhảy lên luôn 2.7 mà không phải là 2.6.16 ??? What the Phúc???

• Sau một thời gian tìm hiểu thì mình cũng biết được keyword đằng sau cái magic này. Không phải là muốn đánh số như nào cũng được đâu. Cái gì cũng phải có quy luật của nó cả :v
• Cái này người ta gọi là Semantic Versioning – cách tạo version để phân biệt cho mỗi lần release.

2. Semantic Versioning(viết tắt là semver) là cái khỉ khô gì?

• Với những developer thường xuyên xử dụng dependency(thư viện bên thứ 3) chắc hẳn không còn xa lạ với Dependency Hell(Dịch nôm na là Địa Ngục Phụ Thuộc) . Khi hệ thống của các bạn đang càng ngày càng lớn dần lên các packages càng được xử dụng nhiều thì việc xung đột phiên bản là điều không thể tránh khỏi. Việc bảo trì và phát triển thêm cũng càng trở nên khó khăn hơn rất nhiều.
• Đây là phương pháp được chuẩn hóa, chấp thuận và được sử dụng cực kì phổ biến, đặc biệt trong việc tạo phiên bản cho Library, Framework, Toolkit, SDK… Sở dĩ được sử dụng phổ biến như vậy là vì phương pháp này giúp cho việc theo dõi tính tương thích (compatibility) trở nên dễ dàng.
• Compatibility cực kì quan trọng trong việc phát triển Library, bởi Library sẽ được sử dụng bởi các developer khác. Public APIs của Library phải đảm bảo không thay đổi nếu không các phần mềm sử dụng Library này sẽ chết bất đắc kì tử khi public APIs thay đổi mà không báo trước.
• Theo Semantic Versioning thì version number về cơ bản sẽ có format như sau → x.y.z Mình sẽ giải thích chi tiết x,y,z là gì ở phía dưới nghen.

3. Tại sao Semantic Versioning lại quan trọng trong phát triển phần mềm?

1. Nó cho phép các nhà phát triển(developer) theo dõi các thay đổi. Khi nào có bản update mới, bản update mới là gì, có bao nhiêu thay đổi.v.v.
2. Chúng ta có thể so sánh các thay đổi từ phiên bản này sang phiên bản khác có gì mới…etc.
3. Giúp developer tránh được những thứ gọi là Dependency Hell (Cái này xảy ra khi phần mềm hoạt động bất thường hoặc hiển thị lỗi và lỗi do một phần mềm / ứng dụng tích hợp được phát triển bởi một bên thứ ba).

4. Quy tắc tạo version

1. MAJOR: Đại diện cho việc thay đổi lớn, không tương thích với bản cũ.

2. MINOR: Đai diện cho những thay đổi nhỏ, vẫn tương thích với bản cũ, nó sẽ khác với PATCH là thay vì update một cái gì đó sẽ thành create một cái gì đó.

3. PATCH: Đại diện cho những thay đổi nhỏ, vẫn tương thích với bản cũ, thường thay đổi sẽ là update gì đó.

4. Pre-Release and Build: Các bản pre-release có thể biểu diễn thêm bằng cách thêm kí tự gạch ngang (-) đi kèm với kí tự ASCII. Bản pre-release báo hiệu rằng đây không phải là một version hoàn chỉnh. Ví dụ như 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.–.

   ⇒ Dựa vào việc giải thích trên, chúng ta có thể hoàn toàn dựa vào hoàn cảnh của từng lần release khác nhau để quyết định tăng MAJOR, PATCH hay MINOR.

   NOTE: Ngoài ra bạn có thể tham khảo 11 quy tắc tạo version tại đây: Semantic Versioning Specification (SemVer)

5. Các kiểu Versioning khác

Mặc dù Semantic Versioning gần như là phương pháp tạo phiên bản phổ biến nhất nhưng chúng ta cũng có thể tham khảo một vài cách khác ở dưới đây:

1. CalVer: Kiểu này thì dựa vào ngày phát hành, nó không cụ thể như Semver nhưng được sử dụng bởi các dự án như Pip trên package Python và Ubuntu

2. Python Versioning Scheme: Một lược đồ định nghĩa để xác định các bản phân phối(distributions) của Python. Lược đồ(scheme) này thì sử dụng 5 phân đoạn là epoch(kỷ nguyên), release(phát hành), pre-release(chuẩn bị phát hành), post-release(sau khi phát hành) và cuối cùng là development(phát triển).

3. Named Versions: Một số dự án chọn đặt tên cho bản phát hành của họ bằng một tên duy nhất. Ví dụ: Android có một bộ sưu tập tên phiên bản rất thú vị bắt đầu bằng Cupcake, Donut, Eclair. Mọi người có thể xem danh sách đầy đủ các bản phát hành Android nếu cần

4. Spring Project Version Naming: Phương pháp này thì phổ biến với các dự án Spring Framework và Spring Boot

…etc.

6. Kết luận

• Semantic Versioning không phải là phương pháp tạo phiên bản duy nhất, nhưng nó là phổ biến, đặc biệt trong các dự án mã nguồn mở.
• Quy tắc semver rất quan trọng, khi dự án của các bạn lớn dần lên thì việc sử dụng semver sẽ rất cần thiết. Để tránh tình trạng bị xung đột giữa các packages các bạn cần phải sử dụng Syntax một cách hợp lý. Hi vọng bài viết sẽ phần nào mang lại cho các bạn kiến thức về semver và có giải pháp thoát ra khỏi Dependency Hell.

Blog của mình: https://tienvm.com/

Đừng quên like, clip bài viết để ủng hộ mình nhé. Đừng quên để lại comment ở dưới nhé 👄