Skip to content

Semantic Versioning 2.0.0

Cấu trúc một phiên bản

​ Cấu trúc phiên bản gia tăng như sau

[MAJOR].[MINOR].[PATCH]

1. Số phiên bản MAJOR khi bạn có những thay đổi API lớn, không tương thích với phiên bản trước
2. Số phiên bản MINOR khi bạn thêm chức năng tương thích ngược với phiên bản trước
3. Số phiên bản PATCH khi bạn làm một bản vá lỗi tương thích ngược với phiên bản trước
4. Các nhãn (labels) bổ sung cho pre-release và các build metadata về quá trình dựng đươc coi là tiện ích mở rộng cho định dạng MAJOR.MINOR.PATCH.

Ex:
1.2.34
1.0.0-alpha
1.0.0-release

Các điểm cần chú ý khi phát hành phiên bản

​ Một chữ số phiên bản bình thường PHẢI lấy từ mẫu X.Y.Z. X, Y và Z là một số nguyên không âm, và KHÔNG chứa số 0 ở đầu. X là phiên bản chính, Y là phiên bản Minor và Z là phiên bản Patch lỗi. Mỗi phần tử cần PHẢI là một số tăng dần. Cho ví dụ: 1.9.0 -> 1.10.0 -> 1.11.0.

​ Một khi gói đã đánh phiên bản được phát hành, nội dung của phiên bản đó KHÔNG được sửa đổi. Mọi sửa đổi PHẢI được phát hành dưới dạng phiên bản mới.

​ Phiên bản Major zero (0.y.z) dành cho giai đoạn phát triển sơ khai. Mọi thứ CÓ THỂ thay đổi bất cứ lúc nào. Public API KHÔNG NÊN được coi là ổn định.

​ Phiên bản 1.0.0 được xác định public API. Cách tăng số phiên bản sau bản phát hành này phụ thuộc vào sự thay đổi của public API.

​ *** Phiên bản Patch Z (x.y.Z) PHẢI được tăng dần nếu chỉ các bản vá tương thích ngược được tung ra**.

​ *** Phiên bản Minor Y (x.Y.z) PHẢI được tăng dần nếu có thêm thay đổi mới và tương thích ngược với phiên bản trước được đưa vào trong public API. Nó PHẢI được tăng dần nếu bất kỳ chức năng API công khai nào đã được đánh dấu là không còn dùng nữa. Nó CÓ THỂ tăng dần nếu chức năng mới hoặc cải tiến mới đáng kể được giới thiệu trong mã đóng. Nó CÓ THỂ bao gồm thay đổi cấp độ bản vá. Phiên bản vá Patch PHẢI được đặt lại về bằng 0 khi tăng phiên bản Minor**.

​ *** Phiên bản Major X (X.y.z với X > 0) PHẢI được tăng dần nếu bất kỳ một thay đổi không tương thích ngược đưa vào API công khai. Nó CÓ THỂ bao gồm phiên bản Minor và thay đổi cấp độ bản vá Patch. Bản vá Patch và phiên bản Minor PHẢI được đặt lại về số 0 khi phiên bản chính tăng lên**.

​ Phiên bản pre-release CÓ THỂ được mô tả bằng cách nối thêm một dấu gạch nối vào một loạt số nhận dạng được phân tách bằng dấu chấm ngay sau phiên bản Patch. Mã định danh PHẢI bao gồm chữ số trong bảng mã ASCII và dấu gạch nối [0-9A-Za-z]. Mã định danh KHÔNG được để trống. Số định danh KHÔNG được bao gồm các chữ số 0 đứng đầu. Các phiên bản pre-release có một độ ưu tiên thấp hơn so với các phiên bản bình thường có liên quan. Một phiên bản pre-release cho biết phiên bản này không ổn định và có thể không đáp ứng các yêu cầu tương thích như dự định giống như là các phiên bản bình thường của nó. Ví dụ: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

​ Build metadata CÓ THỂ được biểu thị bằng cách thêm một dấu cộng và một loạt các tiền tố nhận dạng được phân tách bằng dấu chấm ngay sau phiên bản Patch hoặc phiên bản pre-release. Mỗi định danh PHẢI bao gồm chỉ các chữ số trong bảng mã ASCII và gạch nối [0-9A-Za-z]. Mỗi định danh KHÔNG được rỗng. Build metadata NÊN bỏ qua khi xác định mức độ ưu tiên của phiên bản. Do đó hai phiên bản chỉ khác nhau trong build metadata, có cùng mức độ ưu tiên. Ví dụ: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

Mức độ ưu tiên của phiên bản

​ Mức độ ưu tiên PHẢI được tính bằng cách phiên bản thành các mã định dạng phiên bản Major, phiên bản Minor và phiên bản Patch, theo thứ tự đã nêu. (Build metadata không tính vào mức độ ưu tiên)

​ Mức độ ưu tiên được xác định bởi sự khác biệt đầu tiên khi so sánh từng mã định danh từ trái qua phải. Phiên bản Major -> phiên bản Minor -> phiên bản Patch. ​ Ví dụ: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1.

​ Trong trường hợp phiên bản Major, Minor và Path đều bằng nhau, phiên bản phát hành trước có mức độ ưu tiên thấp hơn. ​ Ví dụ: 1.0.0-alpha < 1.0.0.

​ Mức độ ưu tiên của hai phiên bản pre-release có cùng phiên bản Major, Minor và Patch PHẢI được xác định bằng cách so sánh từng mã định danh phân tách bằng dấu chấm từ trái sang phải cho đến khi tìm thấy sự khác biệt. ​ Ví dụ: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0

Phiên bản trong phát triển phần mềm

​ Trong phần mềm khi build thường có versionName và versionCode.

* **versionName** : là tên (only text) của phiên bản, được đặt theo như trên đã đề cập.
* **versionCode** : là **một số nguyên dương**, **<u>PHẢI được tăng dần trong các bản build</u>**.

​ Do versionCode tăng dần nên ta có thể đặt và bắt đầu từ 1. Tuy nhiên để dễ đặt và quản lý. Còn tùy theo phiên bản, có thể có nhiều team sẽ phát triển trước các phiên bản khác nhau. Do đó ta nên đề ra 1 cấu trúc để phát hành bản build.

​ Ý tưởng là dựa vào versionName, mỗi số X.Y.Z sẽ có 1 bội số. Sau đó ta ghép các bội số đó lại với nhau rồi chuyển thành số nguyên.

X : 0 - 99
Y : 0 - 99
Z : 0 - 999
buildCode : 0 - 999
# -- Ex
0.1.0 buildCode 1 => 0 + 01 + 000 + 001 => 001000001 => số nguyên 1000001
12.34.56 buildCode 78 => 12 + 034 + 056 + 078 => 12034056078 => số nguyên 12034056078