Trong lĩnh vực phần mềm, các bạn có thể nhận thấy rằng bất cứ khi nào một phần mềm nào đó được phát hành hoặc cập nhật thì chúng ta sẽ luôn luôn thấy thông tin về version (phiên bản) của nó. Điều này ngoài việc giúp cho người dùng biết được phần mềm đang ở giai đoạn nào thì còn giúp các hệ điều hành trên máy tính có thông tin để quản lý các phần mềm đó. Ngoài ra, version của phần mềm cũng giúp cho chúng ta – các LTV theo dõi và kiểm soát những gì đã được thêm/xóa/sửa đối với chính software mà chúng ta đang phát triển hoặc software của các đối tác khác mà chúng ta đang sử dụng. Điều này là cực kỳ quan trọng khi chúng ta phát triển một hệ thống lớn, và hệ thống của chúng ta phụ thuộc vào nhiều thư viện khác (dependencies) cũng đang trong quá trình phát triển, nếu chúng ta không kiểm soát sự thay đổi của các dependencies thì phần mềm của chúng ta cũng sẽ trở thành một đống shit đầy lỗi hoặc thậm chí không thể chạy được.
Có một bộ các quy tắc chung mà chúng ta nên tuân theo khi đánh version cho software gọi là Semantic Versioning.
Theo Semantic Versioning thì version number về cơ bản sẽ có format như sau →
x.y.z
Trong đó:
- x – MAJOR version: tăng khi bạn thực hiện các thay đổi dẫn đến KHÔNG tương thích ngược.
- y – MINOR version: tăng khi bạn thêm tính năng và vẫn đảm bảo tương thích ngược (backwards-compatible).
- z – PATCH version: tăng khi bạn thực hiện fix lỗi xử lý bên trong và vẫn đảm bảo tương thích ngược (backwards-compatible)
Ngoài ta cũng có thể có thêm các nhãn bổ sung đằng sau đối với các bản pre-release, cái này sẽ giải thích ngay ở phần bên dưới.
Các quy tắc trong Semantic Versioning (SemVer)
- Software mà sử dụng Semantic Versioning thì PHẢI cung cấp và mô tả một danh sách public API. API này có thể được mô tả ngay trong chính mã nguồn hoặc trong tài liệu đi kèm. Các API cần phải được mô tả chính xác và đầy đủ.
- Một phiên bản bình thường PHẢI có dạng x.y.z (như đã nói ở trên) trong đó x, y và z là các số nguyên không âm, KHÔNG ĐƯỢC chứa số 0 đằng trước và phải đánh tăng dần sau mỗi lần release. Ví dụ: 1.9.0 → 1.10.0 → 1.11.0
- Khi một phiên bản mới đã được phát hành thì nội dung của phiên bản đó KHÔNG ĐƯỢC sửa đổi. Mọi sửa đổi xảy ra sau đó PHẢI được phát hành dưới phiên bản mới.
- Major version X sẽ bằng 0 (0.y.z) với những phiên bản phát triển ban đầu. Đó là thời điểm mà bất cứ điều gì có thể thay đổi bất cứ lúc nào. Public API của software khi đó là chưa đẩy đủ và không ổn định.
- Version 1.0.0 là phiên bản mà public API của nó đã khá đầy đủ (ổn định hay không thì chưa biết). Mọi sự thay đổi từ đó về sau sẽ phụ thuộc vào sự thay đổi được thực hiện đối với public API này.
- Patch version Z (x.y.Z | x > 0) PHẢI được tăng nếu phiên bản mới chỉ fix các lỗi hoạt động bên trong của API và vẫn đảm bảo tương thích ngược (interface của public API không thay đổi)
- Miner version Y (x.Y.z | x> 0)
- PHẢI được tăng nếu có function mới được thêm vào public API nhưng vẫn đảm bảo tương thích ngược.
- PHẢI được tăng lên nếu bất kỳ function nào của public API được đánh dấu là không dùng nữa (deprecated).
- CÓ THỂ được tăng lên nếu trong private code có thay đổi đáng kể về thuật toán, xử lý bên trong của một hoặc nhiều function.
- Patch version Z PHẢI reset về 0 khi tăng Miner version Y
- Major version X (X.y.z | X > 0)
- PHẢI được tăng lên nếu có bất kỳ thay đổi không tương thích ngược nào được thực hiện trên public API.
- Miner version Y và Patch version Z PHẢI reset về 0 khi tăng Major version X
- Phiên bản tiền phát hành (pre-release). Ví dụ: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
- CÓ THỂ được biểu thị bằng cách nối thêm dấu gạch nối và một loạt ký tự nhận dạng (identifier) được phân tách bằng dấu chấm ngay sau Patch version.
- Các identifier KHÔNG ĐƯỢC để trống và CHỈ bao gồm chữ, số và dấu gạch ngang ASCII [0-9A-Za-z-]
- Các phiên bản pre-release có độ ưu tiên thấp hơn so với phiên bản bình thường tương ứng. Phiên bản pre-release là bản không ổn định và có thể không đáp ứng các yêu cầu tương thích như phiên bản thông thường tương ứng
- Siêu dữ liệu của bản build (build metadata) CÓ THỂ được biểu thị bằng cách nối thêm dấu cộng vào sau Patch version hoặc pre-release version, theo sau đó là một loạt các ký tự nhận dạng (identifier) được phân tách bằng dấu chấm. Ví dụ: 1.0.0-alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85
- Các identifier KHÔNG ĐƯỢC để trống và CHỈ bao gồm chữ, số và dấu gạch ngang ASCII [0-9A-Za-z-].
- NÊN bỏ qua build metadata khi xác định độ ưu tiên của phiên bản. Tức là, 2 phiên bản chỉ khác nhau trong build metadata thì có cùng mức độ ưu tiên.
Hy vọng thông tin ở bài này có thể giúp ích cho các bạn khi đánh version cho phiên bản phần mềm mới mà các bạn đang phát triển hoặc nhận biết được mức độ thay đổi trong phiên bản mới của các thư viện mà các bạn đang sử dụng.
— Phạm Minh Tuấn (Shun) —
