Phiên bản cập nhật thực sự có ý nghĩa gì?

Rất nhiều bản cập nhật phần mềm tuân theo sơ đồ của v0.1 đến v0.2 đến v2.6.5.6 . Những "cập nhật" này cho phần mềm thực sự có ý nghĩa gì? Có một tiêu chuẩn ngành nào luôn tuân theo hoặc các lập trình viên có thể tiếp tục nâng cấp # hoặc thêm số thập phân không?

Giống như Shaun đã nói, thực sự không có một tiêu chuẩn nào. Một số công ty có các thực tiễn phiên bản tốt hơn các công ty khác (Tôi đã giao dịch với các nhà cung cấp bỏ qua các số phiên bản chính và các công ty khác bị mắc kẹt trên cùng một số bản phát hành sau đó).

Phải nói rằng, nhà phát minh Gravatars và đồng sáng lập của GitHub ( Tom Preston-Werner ) đã viết một tài liệu cho ' Phiên bản ngữ nghĩa ' rất đáng để đọc.

Đây là ngoại lệ của phần giới thiệu:

Để giải quyết vấn đề này, tôi đề xuất một bộ quy tắc và yêu cầu đơn giản chỉ ra cách thức số lượng phiên bản được gán và tăng. Để hệ thống này hoạt động, trước tiên bạn cần khai báo API công khai. Điều này có thể bao gồm các tài liệu hoặc được thực thi bởi chính mã. Bất kể, điều quan trọng là API này phải rõ ràng và chính xác. Khi bạn xác định API công khai của mình, bạn giao tiếp các thay đổi với API với số gia cụ thể đến số phiên bản của bạn. Xem xét một định dạng phiên bản của XYZ (Major.Minor.Patch). Sửa lỗi không ảnh hưởng đến việc tăng API phiên bản vá lỗi, bổ sung / thay đổi API tương thích ngược làm tăng phiên bản nhỏ và thay đổi API không tương thích ngược làm tăng phiên bản chính.

Tôi gọi hệ thống này là "Phiên bản ngữ nghĩa." Theo sơ đồ này, số phiên bản và cách chúng thay đổi truyền đạt ý nghĩa về mã cơ bản và những gì đã được sửa đổi từ phiên bản này sang phiên bản tiếp theo.

Với 4 chữ số, nó thường là MajorV.MinorV.PatchNum.BuildNum, ít nhất là nơi tôi làm việc.

Cá nhân tôi thích sơ đồ phiên bản của Ubuntu - làm cho cuộc sống dễ dàng hơn nhiều.

Phiên bản ngắn là không có tiêu chuẩn và các công ty làm bất cứ điều gì họ muốn. Về cơ bản, bạn càng có nhiều số, số lượng thay đổi mà mỗi số thể hiện càng nhỏ. Thông thường, bạn sẽ thấy ít nhất phiên bản xy, trong đó xa thay đổi trong x biểu thị các bản phát hành chính (bản nâng cao chính / tính năng) và y biểu thị các bản phát hành nhỏ (chỉnh sửa hoặc sửa lỗi đáng kể). Nhiều số thập phân sau hai thứ đó có thể có nghĩa là những thứ khác nhau trong nội bộ công ty mặc dù thường xoay quanh các bản dựng hoặc bản vá nội dung nhỏ thể hiện các bản sửa lỗi nhanh hơn và nhỏ hơn.

Wikipedia có một bài viết bao gồm điều này chi tiết hơn.

Mục đích của số phiên bản là cung cấp tài liệu tham khảo cho các báo cáo vấn đề. Yêu cầu duy nhất là mỗi bản phát hành có một số phiên bản duy nhất. Một số con số được thúc đẩy bởi tiếp thị - số nguyên lớn hơn dễ bán hơn và các số sức mạnh như 10 (chữ số La Mã X) thực sự hấp dẫn. Một số người sử dụng một số biến thể của phiên bản ngữ nghĩa:

MAJOR.MINOR.MICRO.BUILD

• Gia số chính: thay đổi không tương thích hoặc thiết kế lại hoàn toàn giao diện người dùng
• Gia số nhỏ: các tính năng mới được thêm vào, tương thích với các phiên bản trước trong cùng số phiên bản chính
• Gia số vi mô: phát hành sửa lỗi
• Số bản dựng: được tạo bởi trình biên dịch hoặc được kéo từ kiểm soát phiên bản

Nhiều nhóm bỏ số BUILD trong bản phát hành của họ. Nó thường chỉ hữu ích giữa các nhóm thử nghiệm và phát triển.

Một số nhóm thêm ngữ nghĩa bổ sung, chẳng hạn như số gia MINOR được đánh số lẻ là dành cho các bản dựng thử nghiệm và số gia MINOR được đánh số chẵn được dành cho các bản phát hành sản xuất ( nhân Linux sử dụng phương pháp này).

Điểm mấu chốt là không có tiêu chuẩn, ngoài các phiên bản mới hơn sử dụng số phiên bản cao hơn và mỗi số phiên bản là duy nhất.