Bạn sử dụng phiên bản đặt tên phiên bản nào? [đóng cửa]

Các quy ước đặt tên phiên bản khác nhau có phù hợp với các dự án khác nhau không? Bạn dùng gì và tại sao?

Cá nhân, tôi thích số bản dựng theo hệ thập lục phân (ví dụ 11BCF), số này phải được tăng lên rất thường xuyên. Và sau đó cho khách hàng một số phiên bản 3 chữ số đơn giản, tức là 1.1.3.

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.

Tôi thấy mình hiếm khi đồng ý hoàn toàn với Jeff Atwood, nhưng tôi có xu hướng làm theo ý kiến ​​của anh ấy về quy ước đánh số phiên bản .NET .

(Phiên bản chính). (Phiên bản nhỏ). (Số sửa đổi). (Số bản dựng)

Thường xuyên hơn không, đối với các dự án cá nhân, tôi thấy điều này là quá mức cần thiết. Một vài lần tôi đã làm việc trong các dự án lớn như công cụ tìm kiếm trong C # tôi đã mắc kẹt với quy ước này và đã có thể sử dụng nó như một công cụ theo dõi nội bộ một cách hiệu quả.

Phiên bản ngữ nghĩa ( http://semver.org/ ) xứng đáng được đề cập ở đây. Nó là một đặc tả công khai cho một sơ đồ phiên bản, ở dạng [Major].[Minor].[Patch]. Động lực cho kế hoạch này là truyền đạt ý nghĩa với số phiên bản.

Tôi không sử dụng nó nhưng tôi đã thấy và đó là một cấu trúc thú vị:

Năm.Month.Day.Build

Tự giải thích.

Tôi cố gắng sử dụng chính sách Phiên bản hợp lý của RubyGems trong đó:

• Số phiên bản chính được tăng lên khi khả năng tương thích nhị phân bị phá vỡ
• Số phiên bản nhỏ được tăng lên khi chức năng mới được thêm vào
• Số lượng bản dựng thay đổi để sửa lỗi.

Đây là cách tiếp cận rất chi tiết để đánh số phiên bản:

• N.x.K, ở đâu Nvà Klà số nguyên. Ví dụ: 1.x.0, 5.x.1, 10.x.33. Được sử dụng cho các bản dựng trung gian .
• N.M.K, ở đâu N, Mvà Klà số nguyên. Ví dụ: 1.0.0, 5.3.1, 10.22.33. Được sử dụng để phát hành .
• N.x.x, đâu Nlà số nguyên. Ví dụ : 1.x.x. Được sử dụng cho các chi nhánh hỗ trợ .
• N.M.x, ở đâu Nvà Mlà số nguyên. Ví dụ : 1.0.x. Được sử dụng cho các chi nhánh phát hành .

Dưới đây là hình ảnh minh họa đơn giản về phương pháp đánh số phiên bản:

PAcó nghĩa là tiền alpha A có nghĩa là alpha B có nghĩa là beta AR có nghĩa là phát hành alpha BR có nghĩa là phát hành beta RC có nghĩa là ứng cử viên phát hành ST có nghĩa là ổn định

Ưu điểm của phương pháp đánh số phiên bản như sau:

• Nó đại diện cho các chi tiết cụ thể của vòng đời phát triển phần mềm nhanh .
• Nó sẽ đưa vào chi tiết cụ thể tài khoản của cấu trúc kho mã nguồn .
• Đó là tự giải thích cho những người đã quen với các mẫu. Mỗi mẫu đại diện cho tạo tác khác nhau. Các mẫu như vậy có thể dễ dàng được phân tích cú pháp và sử dụng cho các mục đích khác, chẳng hạn như theo dõi vấn đề.
• Các mẫu phiên bản được đặt, cơ bản cho phương pháp tiếp cận phiên bản được mô tả có thể được sử dụng để thu thập số liệu và lập kế hoạch .
• Nó tập trung vào các khái niệm trưởng thành và mức độ chất lượng . Rất thường các số phiên bản như 1.0.0 được gán mà không cần thiết nhiều (khi phần mềm ở trạng thái alpha sâu). Phương pháp đánh số phiên bản được trình bày cho phép thiết lập một số mức trưởng thành. Trong trường hợp đơn giản nhất, nó sẽ chỉ có hai cấp độ: xây dựng trung gian ( N.x.K) và phát hành ( N.M.K). Phát hành có nghĩa là phần mềm có số phiên bản đầy đủ ( N.M.K) đã trải qua một số loại quy trình quản lý chất lượng trong công ty / tổ chức / nhóm nhà cung cấp.
• Nó là một bằng chứng về bản chất nhanh nhẹn của cả phát triển và thử nghiệm.
• Khuyến khích cách tiếp cận mô-đun cho cấu trúc và kiến ​​trúc phần mềm.

Ngoài ra còn có sơ đồ phức tạp hơn đại diện cho cách tiếp cận phiên bản chi tiết. Ngoài ra, bạn có thể tìm thấy các slide thuyết trình hữu ích mô tả quá trình chuyển đổi sang cách tiếp cận phiên bản và ứng dụng SCMFViz minh họa các nguyên tắc cơ bản của phương pháp đánh số phiên bản. Các slide thuyết trình cũng giải thích tại sao điều quan trọng là phải tuân theo cách tiếp cận phiên bản tương tự trong suốt toàn bộ vòng đời của dự án phần mềm.

Cá nhân tôi thái độ đối với việc sử dụng phiên bản ngày thay vì số phiên bản thực cho rằng các nhà phát triển phần mềm có phiên bản ngày:

• Không biết gì về vòng đời phát triển phần mềm . Phát triển thường nhanh nhẹn và lặp đi lặp lại. Phương pháp đánh số phiên bản nên thể hiện bản chất lặp của quy trình phát triển phần mềm.
• Đừng quan tâm đến chất lượng phần mềm . Kiểm soát chất lượng và đảm bảo là nhanh nhẹn và lặp đi lặp lại. Cũng giống như sự phát triển. Và số phiên bản phải là bằng chứng về bản chất nhanh và lặp của cả phát triển và kiểm soát / đảm bảo chất lượng.
• Đừng quan tâm đến kiến ​​trúc hoặc ý tưởng về ứng dụng của họ. Số phiên bản chính ( Nin N.M.K) chịu trách nhiệm cho cả giải pháp kiến ​​trúc và nguyên tắc cơ bản của ứng dụng. Số phiên bản chính Nsẽ được thay đổi tương ứng với những thay đổi trong kiến ​​trúc hoặc thay đổi các ý tưởng và nguyên tắc chính trong hoạt động / hoạt động của nó.
• Không có quyền kiểm soát cơ sở mã của họ . Có lẽ chỉ có một nhánh (thân cây) và nó được sử dụng cho mọi thứ. Mà cá nhân tôi không nghĩ là đúng vì nó khuyến khích codebase trở thành một bãi rác lớn.

Cách tiếp cận này có vẻ hơi gây tranh cãi, nhưng tôi tin rằng đây là cách đơn giản nhất để đưa ra số phiên bản phần mềm phù hợp.

Đối với mọi phiên bản chính bạn phát hành, không có gì lạ khi có phiên bản hoạt động mà bạn gọi nó là nội bộ. Chẳng hạn, ở công việc cuối cùng của tôi, chúng tôi đã đề cập đến một phiên bản chính với quy ước đặt tên lấy cảm hứng từ Ubuntu sau đây:

[tình trạng ốm yếu] [tên động vật dị ứng]

Trong đó có những cái tên như " Limp Lamprey ", " Wombed Wombat " và " Asthmatic Anteater ".

Hãy chắc chắn trừ khi đó là một cái tên thực sự hay mà nó không rò rỉ cho khách hàng của bạn.

Thế hệ.Version.Revision.Build (9,99.999.9999)

Thế hệ hiếm khi thay đổi. Chỉ có một bước ngoặt lớn trên sản phẩm: DOS -> Windows, tái cấu trúc hoàn chỉnh.

Phiên bản dành cho những thay đổi lớn không tương thích, chức năng mới, thay đổi trên một số mô hình cụ thể trên phần mềm, v.v.

Sửa đổi thường được thực hiện (tính năng nhỏ và sửa lỗi).

Xây dựng là thông tin nội bộ.

git describecung cấp một phần mở rộng tốt đẹp cho bất kỳ quy ước đánh số nào bạn đã chọn. Thật dễ dàng để nhúng cái này vào quá trình xây dựng / đóng gói / triển khai của bạn.

Giả sử bạn đặt tên cho phiên bản phát hành được gắn thẻ ABC (Major.minor.maintenance). git describetrên một cam kết nhất định sẽ tìm thấy tổ tiên được gắn thẻ gần đây nhất của cam kết, sau đó giải quyết số lần xác nhận kể từ đó và SHA1 viết tắt của cam kết:

1.2.3-164-g6f10c

Dĩ nhiên, nếu bạn thực sự ở một trong các phiên bản, bạn sẽ chỉ nhận được thẻ (1.2.3).

Điều này có lợi ích tốt đẹp là cho bạn biết chính xác nguồn bạn đã xây dựng từ đâu, trong khi không phải tự đánh số mỗi bản dựng.

Major.Minor.Public (bản dựng) [alpha / beta / Trial], chẳng hạn như "4.08c (1290)"

• Với Major là số phiên bản chính (1, 2, 3 ...)
• Phiên bản nhỏ là một phiên bản nhỏ gồm 2 chữ số (01, 02, 03 ...). Thông thường, hàng chục chữ số được tăng lên khi chức năng mới quan trọng được thêm vào, những chức năng chỉ sửa lỗi.
• Công khai là bản phát hành công khai của bản dựng (a, b, c, d, e), thường khác với phiên bản nhỏ nếu một phiên bản nhỏ không bao giờ được phát hành dưới dạng bản cập nhật công khai
• xây dựng, là số xây dựng thực tế mà trình biên dịch theo dõi.
• với TRIAL, ALPHA, BETA X hoặc RC X được thêm vào cho những trường hợp đặc biệt.

Tôi thích số phiên bản gán một số ý nghĩa ngữ nghĩa. Miễn là bạn có thể sử dụng số phiên bản để theo dõi các lỗi được báo cáo với một phiên bản cụ thể đối với các thay đổi xảy ra trong mã nguồn (và trong hệ thống quản lý hoạt động của bạn) thì có lẽ bạn đang sử dụng đúng phương pháp.

Tôi sử dụng .NET vì vậy tôi bị mắc kẹt với hệ thống đánh số phiên bản .NET nhưng tôi cố gắng đưa ra ý nghĩa ngữ nghĩa cho các con số với

chính.minor.build.revision

• chính = (lên đến dự án)
• nhỏ = (lên đến dự án)
• build = build number từ Hudson (bạn có thể sử dụng TeamCity hoặc TeamBuild, v.v. tại đây)
• sửa đổi = lật đổ hoặc sửa đổi chợ (tùy thuộc vào dự án và những gì nó sử dụng)

Chúng tôi luôn đảm bảo rằng số phiên bản của anh ấy có thể được hiển thị theo một cách nào đó (với các chương trình dựa trên bảng điều khiển hàng loạt của chúng tôi được in ra bảng điều khiển và tệp nhật ký, với các ứng dụng web nằm trên thanh menu ở trên cùng)

Bằng cách này, nếu khách hàng báo cáo sự cố, chúng tôi có thể sử dụng số phiên bản để theo dõi nếu họ đang sử dụng phiên bản mới nhất và có bao nhiêu vấn đề chúng tôi gặp phải với các phiên bản cụ thể.

Đó là tất cả về truy xuất nguồn gốc!

Chúng tôi sử dụng Major.Minor.Build # .YYMMDD [hậu tố], vì chúng tôi thường chỉ thực hiện một bản dựng sản xuất vào bất kỳ ngày cụ thể nào (nhưng sử dụng hậu tố ab / c / d nếu có nhiều hơn một) và YYMMDD cung cấp cho người dùng / khách hàng / quản lý một chỉ dẫn về tuổi của bản dựng, trong đó 6.3.1389 thì không.

Số lượng lớn tăng với các tính năng sản phẩm quan trọng (trả tiền).

Số lượng nhỏ tăng lên với các bản sửa lỗi / cải tiến (cập nhật miễn phí).

Xây dựng luôn tăng; không phải tất cả các tàu đóng, vì vậy nó không phải là một sự tiến triển tuyến tính.

Số phiên bản phải có đủ thông tin để bạn tránh xung đột và sửa lỗi trong các vấn đề về loại phát hành sai, nhưng không nên truyền đạt thông tin bổ sung không liên quan.

Chẳng hạn, nếu bạn sử dụng ngày khách hàng có thể nói rằng họ có phiên bản cũ hơn và các bản vá so với phiên bản cũ có thể có phiên bản khó hiểu.

Cá nhân tôi thích phiên bản ngữ nghĩa :

• Phát hành là Major. Minor.Patch
• Patch gia tăng mỗi khi bạn phát hành bản dựng.
• Minor gia tăng mỗi lần chức năng tương thích ngược được thêm vào.
• Major gia tăng khi chức năng mới không tương thích ngược.
• Khi Major== 0 bạn đang ở giai đoạn alpha / tiền phát hành. Major> = 1 là bản phát hành công khai của bạn.
• Số thấp hơn đặt lại về 0 mỗi khi bạn tăng, vì vậy

  1.5.3-> 1.5.4(sửa lỗi) -> 1.6.0(tính năng nhỏ) -> 2.0.0(phá vỡ thay đổi)

              1.0.0
                |
              1.0.1
                |
(công khai 1.0) 1.0.2 -----
                | \
              2.0.0 1.1.0
                | |
              2.0.1 1.1.1 (công khai 1.1)
                |
(công khai 2.0) 2.0.2 -----
                | \
              3.0.0 2.1.0
                         |
                       2.1.1 (công khai 2.1)
                         |
                       2.2.0
                         |
                       2.2.1

X.Y.Zlà số phiên bản nội bộ của chúng tôi. X.Ylà số phiên bản công khai, một số có ý nghĩa với khách hàng của chúng tôi. Khi một X.Y.Zphiên bản trở nên công khai, sẽ không bao giờ có X.Y.(Z+1)phiên bản: phiên bản công khai luôn là phiên bản cuối cùng của serie.

X được tăng lên khi một phiên bản chính được phát hành.

Y được sử dụng cho các nhánh bảo trì của các bản phát hành chính đó, chỉ để sửa lỗi.

Zđược sử dụng trong nội bộ, và không có ý nghĩa cố định. Cho đến bây giờ, tôi tạo một Zphiên bản mới khi tôi nghĩ rằng ứng dụng này có một bộ các tính năng thú vị để hiển thị cho những người không phải là nhà phát triển và tương đối ổn định. Bằng cách này, tôi có thể hiển thị bản demo của "phiên bản tốt được biết đến cuối cùng" của ứng dụng khi ai đó hỏi. Trong tương lai gần, tôi dự định sử dụng các Zphiên bản số để đặt tên cho "mục tiêu" của các tính năng, trong bugtracker của chúng tôi.

Là một lưu ý phụ, chúng tôi sử dụng maven (với releaselệnh) để tăng số phiên bản. Vì vậy, cũng có X.Y.Z-SNAPSHOTcác phiên bản (chỉ ra bất kỳ phiên bản nào giữa X.Y.(Z-1)và X.Y.Z).