Tìm kiếm cách thực hành tốt nhất để đánh số phiên bản của các thành phần phần mềm phụ thuộc

Chúng tôi đang cố gắng quyết định một cách tốt để đánh số phiên bản cho các thành phần phần mềm, tùy thuộc vào nhau.

Hãy cụ thể hơn:

Thành phần phần mềm A là phần sụn chạy trên thiết bị nhúng và thành phần B là trình điều khiển tương ứng cho một PC bình thường (máy Linux / Windows). Họ đang giao tiếp với nhau bằng một giao thức tùy chỉnh. Vì sản phẩm của chúng tôi cũng nhắm đến các nhà phát triển, chúng tôi sẽ cung cấp các phiên bản ổn định và không ổn định (thử nghiệm) của cả hai thành phần (phần sụn là nguồn đóng, trong khi trình điều khiển là nguồn mở). Khó khăn lớn nhất của chúng tôi là làm thế nào để xử lý các thay đổi API trong giao thức truyền thông.

Trong khi chúng tôi đang thực hiện kiểm tra khả năng tương thích trong trình điều khiển - nó sẽ kiểm tra xem phiên bản phần sụn có tương thích với phiên bản của trình điều khiển hay không - chúng tôi bắt đầu thảo luận về nhiều cách đánh số phiên bản.

Chúng tôi đã đưa ra một giải pháp, nhưng chúng tôi cũng cảm thấy muốn sáng tạo lại bánh xe. Đó là lý do tại sao tôi muốn nhận được một số phản hồi từ cộng đồng lập trình viên / nhà phát triển phần mềm, vì chúng tôi nghĩ rằng đây là một vấn đề phổ biến.

Vì vậy, đây là giải pháp của chúng tôi:

Chúng tôi dự định theo dõi cách đánh số phiên bản Major.minor.patch được sử dụng rộng rãi và sử dụng các số phụ chẵn / lẻ cho các phiên bản ổn định / không ổn định. Nếu chúng tôi giới thiệu các thay đổi trong API, chúng tôi sẽ tăng số lượng nhỏ.

Quy ước này sẽ dẫn đến tình huống ví dụ sau:

Chi nhánh ổn định hiện tại là 1.2.1 và không ổn định là 1.3.7. Bây giờ, một bản vá mới cho sự không ổn định thay đổi API, điều gì sẽ khiến số phiên bản không ổn định mới trở thành 1.5.0. Một khi, nhánh không ổn định được coi là ổn định, giả sử trong 1.5.3, chúng tôi sẽ phát hành nó là 1.4.0.

Tôi sẽ rất vui về câu trả lời cho bất kỳ câu hỏi liên quan nào dưới đây:

• Bạn có thể đề xuất một thực tiễn tốt nhất để xử lý các vấn đề được mô tả ở trên?
• Bạn có nghĩ rằng quy ước "tùy chỉnh" của chúng tôi là tốt?
• Những thay đổi bạn sẽ áp dụng cho quy ước được mô tả?

Số phiên bản IMHO giống như tên sản phẩm; quan trọng ở chỗ chúng có thể nhìn thấy nhưng không quan trọng ở chỗ chúng trang trí hơn là nội dung.

Vẫn là số phiên bản, giống như một tên sản phẩm, mang ý nghĩa. Và điều quan trọng nhất bạn có thể làm là tránh nhầm lẫn. Vì vậy, đây là một số kỳ vọng phổ biến liên quan đến số phiên bản. Trong phạm vi mà các ngoại lệ này không được đáp ứng, người dùng có thể sẽ bị nhầm lẫn:

Số phiên bản đang tăng đơn điệu
Đây có lẽ là kỳ vọng rõ ràng nhất, đồng thời ít có khả năng thực sự là sự thật. Nhìn thoáng qua, người dùng hy vọng rằng phiên bản 2.3.5 xuất hiện sau phiên bản 2.2.17 và có công nghệ tương tự hoặc tốt hơn. Nhưng tất nhiên 2.3.x là một nhánh phát triển và 2.2.x ổn định và 2.3.5 thực sự đã được phát hành trở lại vào năm 2004 và nhánh 2.2 vẫn đang tích cực hoạt động và 2.2.17 được phát hành vào tháng 4 năm ngoái và có chứa. .. Chà, bạn hiểu ý rồi đó. Bạn cũng có thể chỉ cần gọi phiên bản 2.2 "Khoai tây" cho tất cả ý nghĩa mà số mang. Chào mừng bạn đến với phiên bản " Khoai tây-17 " !!

Các phiên bản tương tự có thể nâng cấp / tương thích
Nếu tôi có phiên bản 3.7 trên máy tính của mình và 3.8 xuất hiện với tất cả các frozbots sáng bóng mới, tôi hy vọng rằng với một số nâng cấp hoặc bản vá hoặc bất cứ điều gì, 3.7 của tôi có thể trở thành 3,8 mà không bị gián đoạn. Nhưng nếu tôi trên 3.7 và bạn phát hành 5.2, tôi không quá lạc quan. Tất nhiên, tôi thà ngạc nhiên thay vì thất vọng.

Chữ số đầu tiên rất quan trọng
tôi thậm chí sẽ không đề cập đến điều này nếu Java không quá khó hiểu về vấn đề này. Trừ khi có ai đó nói với bạn, bạn sẽ không mong đợi rằng "Java 7" thực sự là phiên bản 1.7. Và lần đầu tiên bạn nghe điều này, bạn đã trả lời gần như chắc chắn: " Cái gì? .. Tại sao? "

Rõ ràng người theo chủ nghĩa thuần túy sẽ nói rằng số phiên bản chính sẽ chỉ thay đổi nếu thay đổi nền tảng không tương thích ngược. Nhưng bạn có thực sự có ý định giảm khả năng tương thích ngược bao giờ không? Thông thường phiên bản chính revs là một quyết định tiếp thị không phải là một kỹ thuật; sự vô lý của Java xuất phát từ cả hai phe cùng một lúc, đến hiệu quả gần như hài hước.

Cuối cùng
Như tôi vừa đề cập, số phiên bản thường nhiều về tiếp thị cũng như về công nghệ. Và điều đó cũng ổn, vì đó là loại số phiên bản dành cho: thông báo cho bạn biết về những gì mới về phần mềm. Thay đổi số lớn có nghĩa là thay đổi chức năng lớn. Thay đổi số nhỏ có nghĩa là hầu như không thay đổi chức năng. Đó là những gì mọi người mong đợi . Điều đó có đúng hay không quyết định liệu số phiên bản của bạn có mang cùng một ý nghĩa mà người dùng của bạn nghĩ rằng họ làm hay không.

- EDIT -
Tôi đã quên đề cập đến vấn đề này, nhưng Caleb đã chỉ ra điều này một cách độc đáo: Đừng sử dụng số phiên bản để biểu thị bất cứ điều gì quan trọng (ví dụ: ổn định / không ổn định) mà không làm cho nó rõ ràng ở nơi khác. Vâng, bạn biết rằng số phiên bản nhỏ lẻ cho thấy sự phát triển, nhưng điều đó làm cho một trong chúng ta. Biệt danh phát hành "không ổn định" của Debian là một ví dụ điển hình; hoặc bạn cũng có thể sử dụng một tên sản phẩm hoàn toàn riêng biệt; "Frozbot 1.2" cho tên sản phẩm của bạn và "Devbot 1.3" cho phiên bản phát triển của bạn.

Một khi, nhánh không ổn định được coi là ổn định, giả sử trong 1.5.3, chúng tôi sẽ phát hành nó là 1.4.0.

Không không. Để ổn định 1.5.3 ổn định phải bắt đầu từ 1.6.0 (và 1.4.x chỉ bị bỏ lỡ, nếu bạn muốn sử dụng Phiên bản ngữ nghĩa)

Bạn đang cố gắng sử dụng một giá trị để chỉ ra hai điều riêng biệt.

Đầu tiên, bạn đã có một "phiên bản", thường phục vụ để xác định các bản phát hành khác nhau và để chỉ ra thứ tự phát hành được thực hiện. Như tylerl đã nói, phiên bản sẽ luôn tăng - nó sẽ không có ý nghĩa gì với người dùng (và nó cũng có thể gây ra nhiều nhầm lẫn bên trong) nếu bạn thay đổi phiên bản từ 1.5.3 sang 1.4.0.

Thứ hai, bạn đang cố gắng chỉ ra liệu một phiên bản nhất định có ổn định hay không.

Có thể chỉ ra cả hai điều với một "số phiên bản" duy nhất, giống như một số cửa hàng sẽ sử dụng một số chương trình định giá để cho biết liệu một mặt hàng có được bán hay không. Ví dụ: giá kết thúc bằng '3' tại cửa hàng gần tôi là giá bán cuối cùng. Điều đó làm việc tốt cho các nhân viên, những người nhanh chóng học cách phát hiện giá bán, nhưng đó không phải là cách hay để nói với khách hàng của bạn về việc bán hàng. Vì lý do đó, họ cũng đưa ra các dấu hiệu gần các mặt hàng bán. Bạn có thể làm một cái gì đó tương tự, như tạo ra chữ số ít quan trọng nhất cho các bản phát hành ổn định chẵn và làm cho nó trở nên kỳ lạ cho các bản phát hành thử nghiệm. Tuy nhiên, tôi nghĩ rằng nếu bạn sẽ phát hành thứ gì đó mang tính thử nghiệm, bạn nên đánh dấu rõ ràng theo cách đó. Bạn có thể thêm 'X' ở đầu hoặc cuối chuỗi phiên bản, như:X.1.5.31.5.3.X. Bạn có thể thậm chí là một số phiên bản thử nghiệm sau đó, vì vậy bạn có thể phát hành nhiều phiên bản thử nghiệm tất cả đều dựa trên cùng một phiên bản cơ sở: 1.5.3.X1, 1.5.3.X2.

Bạn cũng nên xem xét rằng có một truyền thống lâu dài về việc sử dụng số phiên bản "alpha" và "beta" để chỉ ra các phiên bản có thể không ổn định hoặc hoàn chỉnh : 1.5.3a54. Hãy chắc chắn rằng bạn có lý do chính đáng để rời khỏi chương trình này nếu bạn quyết định làm bất cứ điều gì khác, bởi vì có lẽ bạn sẽ phải giải thích bất cứ điều gì khác cho cộng đồng nhà phát triển của mình.

Tôi sẽ đề nghị sử dụng định dạng Major.minor.patch, sử dụng "thẻ" tiện ích mở rộng cho các phiên bản ổn định / không ổn định và ý nghĩa nhất định của các số chính và số phụ:

major.minor.patch-stable|unstable

Ở đâu

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

Cách phụ thuộc này được quản lý dễ dàng và sẽ thông báo cho từng khách hàng / người dùng thành phần khi họ phải chú ý hơn đến các phiên bản mới. Ví dụ: nếu thành phần A (1.1.0 ổn định) phụ thuộc vào B (5.4.534 ổn định) và phiên bản mới của B là do (6.1.0 không ổn định), người ta sẽ biết ngay rằng A sẽ phải thay đổi, có thể là đáng kể .

Tôi thực sự thích cách Hibernating Rhinos đã xây dựng các phiên bản vis-a-vis RavenDb - chúng chỉ có số lượng bản dựng ngày càng tăng. Khi họ có được một cái ổn định, nó được đánh dấu ổn định. Nhưng tất cả mọi thứ là một ứng cử viên phát hành.