Lược đồ đánh số phiên bản nào để sử dụng?

Question

Tôi đang tìm một lược đồ đánh số phiên bản thể hiện mức độ thay đổi, đặc biệt là tính tương thích.

Apache APR, ví dụ, sử dụng sơ đồ thứ tự phiên bản nổi tiếng

<major>.<minor>.<patch> 
example: 4.5.11 

Maven cho thấy một sơ đồ tương tự nhưng chi tiết hơn:

<major>.<minor>.<patch>-<qualifier>-<build number> 
example: 4.5.11-RC1-3732 

đâu là chương trình versioning Maven được xác định? Có các quy ước về vòng loại và số xây dựng không? Có lẽ đó là một ý tưởng tồi để sử dụng maven nhưng không tuân theo lược đồ phiên bản Maven ...

Bạn có biết các lược đồ đánh số phiên bản nào khác không? Bạn thích chương trình nào hơn và tại sao?

Answer 1

Đây là current Maven version comparison algorithm và discussion. Miễn là các phiên bản chỉ phát triển, và tất cả các trường ngoại trừ số bản dựng được cập nhật theo cách thủ công, bạn tốt. Các vòng loại hoạt động như thế này: nếu một là một tiền tố của cái kia, thì còn lâu hơn. Nếu không, chúng được so sánh theo thứ tự bảng chữ cái. Sử dụng chúng để phát hành trước.

Thứ hai việc sử dụng phiên bản ngữ nghĩa để thể hiện khả năng tương thích; chính là cho các thay đổi không tương thích ngược, nhỏ cho các tính năng tương thích ngược, vá các bản sửa lỗi tương thích ngược. Ghi lại tài liệu để người dùng thư viện của bạn có thể thể hiện sự phụ thuộc vào thư viện của bạn một cách chính xác. Ảnh chụp nhanh của bạn được tự động và không phải tăng các ảnh này, ngoại trừ ảnh chụp nhanh đầu tiên sau khi phát hành vì các tiền tố được so sánh.

Answer 2

Tôi muốn giới thiệu tiêu chuẩn Phiên bản ngữ nghĩa, mà hệ thống phiên bản Maven cũng xuất hiện. Vui lòng kiểm tra ra,

http://semver.org/

Nói tóm lại nó là <major>.<minor>.<patch><anything_else>, và bạn có thể thêm các quy tắc bổ sung cho phần bất cứ thứ gì như có vẻ phù hợp với bạn. ví dụ. -<qualifier>-<build_number>.

Answer 3

Sau khi đọc rất nhiều bài viết/QA/Câu Hỏi Thường Gặp/cuốn sách tôi trở nên suy nghĩ rằng [MAJOR]. [NHỎ]. [REV] là schema phiên bản hữu ích nhất để mô tả khả năng tương thích giữa các phiên bản dự án (versioning schema dành cho nhà phát triển, không dành cho tiếp thị).

YẾU thay đổi này là lạc hậu không tương thích và yêu cầu thay đổi tên dự án, đường dẫn đến file, GUID vv

NHỎ thay đổi tương thích ngược. Đánh dấu giới thiệu các tính năng mới .

REV để bảo mật/sửa lỗi. Tương thích ngược và tiến.

schema phiên bản này lấy cảm hứng từ libtool ngữ nghĩa versioning và bởi bài viết:

http://www106.pair.com/rhp/parallel.html

LƯU Ý: tôi cũng khuyên bạn nên cung cấp build/ngày/tùy chỉnh/chất lượng thông tin như bổ sung (xây dựng số, ngày xây dựng, tên khách hàng, chất lượng phát hành):

Xin chào ứng dụng v2.6.34 cho ngân hàng quốc gia, 2011-05-03, beta, xây dựng

Nhưng thông tin này là không versioning thông tin!

Answer 4

Hoàn toàn cho sự hoàn chỉnh, tôi sẽ đề cập đến số old Apple standard for version numbers. Điều này có vẻ như phiên bản chính. phiên bản phụ. phiên bản lỗi. giai đoạn. phiên bản không phát hành. Stage là một mã số rút ra từ tập d (phát triển), một (alpha), b (beta), hoặc fc (tàu khách hàng cuối cùng - nhiều hay ít tương tự như phiên bản RC, tôi nghĩ rằng) .

Phiên bản và bản sửa đổi không phát hành chỉ được sử dụng cho các phiên bản không có bản phát hành phù hợp.

Vì vậy, phiên bản đầu tiên của thứ gì đó có thể là 1.0.0. Bạn có thể đã phát hành một bugfix là 1.0.1, một phiên bản mới (với nhiều tính năng hơn) là 1.1, và một bản viết lại hoặc nâng cấp lớn là 2.0. Nếu sau đó bạn muốn làm việc theo hướng 2.0.1, bạn có thể bắt đầu với 2.0.1d1, 2.0.1d2, thành 2.0.1d153 hoặc bất kỳ thứ gì bạn đã đưa ra, sau đó gửi 2.0.1a1 đến QA và sau khi họ đã phê duyệt 2.0.1a37 , gửi 2.0.1b1 cho một số người chơi sẵn sàng, sau đó sau khi 2.0.1b9 sống sót sau một tuần trong lĩnh vực này, hãy ghi 2.0.1fc1 và bắt đầu nhận được signoff. Khi 2.0.1fc17 có đủ, nó sẽ trở thành 2.0.1, và sẽ có nhiều hân hoan.

Định dạng này đã được chuẩn hóa đủ để có định dạng nhị phân được đóng gói cho nó và các thói quen trợ giúp trong thư viện để so sánh.

Answer 5

Lưu ý rằng lược đồ số phiên bản (như x.y.0 so với x.y) có thể bị hạn chế bởi các yếu tố bên ngoài.

Hãy xem xét rằng announcement for Git 1.9 (Januaury 2014):

Một ứng cử viên phát hành Git v1.9-RC2 bây giờ đã có để thử nghiệm tại các vị trí thông thường.

Tôi đã nghe tin đồn rằng công cụ của bên thứ ba khác nhau không thích những con số phiên bản hai chữ số (ví dụ: "Git 2.0") và bắt đầu barfing trái và phải khi người dùng cài đặt v1.9-rc1 .
Trong khi đó là hấp dẫn để cười vào họ cho giả định cẩu thả của họ, tôi cũng thực tế và không nhớ gọi phát hành sắp tới v1.9.0 để giúp họ.

Nếu chúng ta đi con đường đó (và tôi nghiêng để đi mà tuyến đường tại thời điểm này), chương trình phiên bản sẽ là:

• Các ứng cử viên phát hành tiếp theo sẽ là v1.9.0-rc3, không v1.9-rc3;
• Bản phát hành bảo trì đầu tiên cho v1.9.0 sẽ là v1.9.1 (và thứ N là v1.9.N); và
• Bản phát hành tính năng sau v1.9.0 sẽ là phiên bản v1.10.0 hoặc v2.0.0, tùy thuộc vào độ lớn của tính năng mà chúng tôi đang xem.