Dựa trên kinh nghiệm của tôi về quản lý phụ thuộc cấp nền tảng doanh nghiệp phức tạp và phiên bản phát hành Tôi đã đề xuất phương pháp tôi muốn gọi Phiên bản bán ngữ nghĩa.
Về cơ bản nó được xây dựng từ Semantic Versioning 2.0 nhưng không hoàn toàn nghiêm ngặt.
Version
Semi-Semantic Phân đoạn:
<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]
tiểu phát hành Segment Format:
MARKETTING.MAJOR.MINOR.PATCH
Mỗi phân khúc nên cho phép chữ cái và số, nhưng tinh khiết numerics được đề xuất cho các thay đổi gia tăng hợp lý.
Giống như SemVer, tôi khuyên bạn nên lớn, nhỏ, và Patch thành phần để đại diện cho tầng tương thích ngược, nhưng tôi cũng khuyên bạn nên thêm vào trước một thành phần Tiếp thị. Điều này cho phép chủ sở hữu sản phẩm, sử thi tính năng/nhóm và mối quan tâm kinh doanh để làm nổi bật thành phần chính độc lập với các mối quan tâm về tính tương thích kỹ thuật.
Không giống như các câu trả lời khác, tôi không khuyến khích thêm số Xây dựng vào phân khúc chính.Thay vào đó, hãy thêm Phân đoạn sau khi phát hành theo sau dấu '+' (ví dụ: 1.1.0.0 + build.42). SemVer gọi siêu dữ liệu xây dựng này, nhưng tôi nghĩ rằng Phân đoạn hậu phát hành là rõ ràng hơn. Phân đoạn này rất tuyệt vời để khai báo dữ liệu hậu tố không liên quan đến thông tin tương thích trong Phân đoạn Phát hành chính. Các phiên bản tích hợp liên tục của bạn có thể được cung cấp số phát hành trước đó được nối thêm với số xây dựng gia tăng sẽ đặt lại sau mỗi bản phát hành chính (ví dụ: 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> 1.1.0.1). Một số người luân phiên thích đặt số sửa đổi svn ở đây hoặc git commit sha để dễ dàng liên kết với kho lưu trữ mã. Một tùy chọn khác là sử dụng phân đoạn hậu phát hành cho bản sửa lỗi và bản vá lỗi, có thể đáng xem xét việc thêm thành phần phát hành chính mới cho điều đó. Nó luôn luôn có thể được giảm xuống khi thành phần bản vá được tăng lên, vì các phiên bản được căn trái và sắp xếp một cách hiệu quả.
Bên cạnh những phân đoạn phát hành và sau khi phát hành, người ta thường muốn sử dụng một Pre-Release Segment để chỉ ra gần như ổn định trước khi phát hành như alpha, beta và phát hành các ứng cử viên. Cách tiếp cận SemVer cho điều này hoạt động tốt, nhưng tôi khuyên bạn nên tách các thành phần số khỏi các phân loại alpha-số (ví dụ: 1.2.0.0 + alpha.2 hoặc 1.2.0.0 + RC.2). Thông thường, bạn sẽ va chạm phân khúc phát hành cùng lúc với việc thêm phân đoạn sau khi phát hành và sau đó thả phân khúc tiền phát hành khi bạn tiếp tục làm nổi bật phân đoạn phát hành chính (ví dụ: 1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0). Các phân đoạn tiền phát hành được thêm vào để cho biết rằng phiên bản phát hành sắp ra mắt, thường chỉ là một bộ tính năng cố định để kiểm tra và chia sẻ chuyên sâu hơn mà không thay đổi từng phút dựa trên nhiều cam kết hơn.
Vẻ đẹp của việc xác định tất cả các ngữ nghĩa này theo cách bao quát tất cả các trường hợp sử dụng là bạn có thể phân tích, sắp xếp, so sánh và tăng chúng theo cách tiêu chuẩn. Điều này đặc biệt quan trọng khi sử dụng các hệ thống CI cho các ứng dụng phức tạp với rất nhiều thành phần được phiên bản độc lập nhỏ (như các dịch vụ vi mô) đều có các phụ thuộc được quản lý riêng của chúng.
Nếu bạn quan tâm, tôi đã viết a semi-semantic parser in ruby. Tôi không cần phải sử dụng mẫu này nhưng có thể quản lý các ứng dụng khác đã sử dụng nó.
Sau một thời gian, khi bạn đạt ~ 6 hoặc 7, bạn nên chuyển sang năm 2010 (hoặc bất kỳ năm nào tốt đẹp);) – Anonymous
Arg ... Xin vui lòng, tôi cầu xin bạn, đừng. :-D – DevSolar
http://msdn.microsoft.com/en-us/library/system.version.aspx trong Ghi chú – Kikaimaru