• HOME
  • ABOUT ME
  • C++ CƠ BẢN
  • C++ NÂNG CAO
  • DESIGN PATTERNS
  • CODE GYM
  • TECH365
  • KIẾN THỨC TỔNG HỢP
    • 4 TÍNH CHẤT CỦA OOP
    • LINUX / YOCTO / AOSP
    • VISUAL STUDIO
    • CTDL & GIẢI THUẬT
  • HỎI ĐÁP

Ý nghĩa của Semantic Versioning trong Software

Tháng Tám 7, 2019 Mr.Shun TECH365 0

    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) —

  • build metadata
  • pre-release
  • Semantic Versioning
Trước đó

Là lập trình viên cần phải tò mò để phát triển

Tiếp theo

Giải pháp Integrated Cockpit và Hypervisor trong Automotive

Facebook group

Bài viết mới

  • Bộ tiền xử lý – Preprocessor trong C/C++

    Tháng Mười Hai 28, 2020 0
  • Cùng tìm hiểu về Base64 encoding

    Tháng Mười Một 4, 2020 0
  • 5 cấp độ tự động của công nghệ XE TỰ LÁI (Autonomous Car) hiện nay

    Tháng Mười 21, 2020 0
  • Hãy kiểm soát “temporary objects” trong chương trình C++

    Tháng Mười 8, 2020 0
  • ĐỪNG OVERLOAD (nạp chồng) hàm bằng cách phân biệt tham số kiểu POINTER/NUMERIC

    Tháng Chín 29, 2020 0
  • Virtual Tables (vtable) trong C++

    Tháng Chín 15, 2020 0
  • HÀNH TẨU GIANG HỒ CÙNG C++ CUỒNG ĐAO

    Tháng Tám 28, 2020 0

Chuyên mục

  • 4 TÍNH CHẤT CỦA OOP
  • BEST PRACTICES
  • C++ NÂNG CAO
  • CODE GYM
  • CTDL & GIẢI THUẬT
  • DESIGN PATTERNS
  • KIẾN THỨC TỔNG HỢP
  • LINUX / YOCTO / AOSP
  • TECH365
  • VISUAL STUDIO
Tags
automotive (5) C++ (10) c++ cơ bản (72) c++ nâng cao (3) chuỗi (8) class (3) codefun (3) const (4) con trỏ (4) Cplusplus (14) cppdeveloper (3) Design Patterns (9) Dynamic (2) enum (3) Function (3) Git (2) GitHub (2) hacker (4) Hàm (3) hằng (3) IDE (2) Library (2) linux (9) Lập trình hướng đối tượng (3) memory (2) Microsoft (2) nullptr (3) nạp chồng (2) OOP (4) operator (8) overload (3) override (2) pointer (8) Programming (3) security (3) Solution Architect (2) string (17) structure (2) Tham trị (2) toán tử (13) ubuntu (3) unix (2) Visual Studio (2) Yocto (3) ép kiểu (5)
Bài viết gần đây
  • Top 10 H.A.C.K.E.R khét tiếng nhất mọi thời đại

    Tháng Tám 11, 2020 0
  • Ethical Hacking: TẠI SAO tài khoản Facebook của bạn bị H.A.C.K ? – Phần 2

    Tháng Tám 11, 2020 0
  • Ethical Hacking: TẠI SAO tài khoản Facebook của bạn bị H.A.C.K ? – Phần 1

    Tháng Bảy 25, 2020 0
  • Lambda expression trong C++

    Tháng Bảy 21, 2020 0
  • TOP các forum hàng đầu của H.A.C.K.E.R trên Surfaceweb và Darkweb

    Tháng Bảy 19, 2020 0
  • Một số vấn đề về bảo mật khi xây dựng phần mềm bằng ngôn ngữ C/C++

    Tháng Bảy 18, 2020 0

Copyright © 2021 Cpp•Developer by Phạm Minh Tuấn (Shun)