Thực hành tốt nhất: Phiên bản phần mềm [đã đóng]

Có hướng dẫn hay tiêu chuẩn thực hành tốt nhất nào để phiên bản một phần mềm bạn phát triển trong thời gian rảnh rỗi, nhưng vẫn được một số người sử dụng không? Tôi nghĩ rằng cần phải phiên bản phần mềm như vậy để bạn biết về phiên bản mà người ta đang nói đến (ví dụ: để sửa lỗi, hỗ trợ, v.v.).

Nhưng tôi phải bắt đầu phiên bản ở đâu? 0,0.0? hay 0,0? Và sau đó làm thế nào để tôi tăng số? phát hành lớn.minor thay đổi? và không nên cam kết hệ thống kiểm soát phiên bản là phiên bản khác? hoặc điều này chỉ dành cho các phiên bản được sử dụng một cách hiệu quả?

Bạn nên bắt đầu với phiên bản 1, trừ khi bạn biết rằng phiên bản đầu tiên bạn "phát hành" chưa hoàn chỉnh theo một cách nào đó.

Đối với cách bạn tăng các phiên bản, điều đó tùy thuộc vào bạn, nhưng hãy sử dụng số chính, phụ, xây dựng số làm hướng dẫn.

Không cần thiết phải có mọi phiên bản bạn cam kết kiểm soát nguồn như một phiên bản khác - thực sự bạn sẽ sớm có số phiên bản rất lớn. Bạn chỉ cần tăng số phiên bản (theo một cách nào đó) khi bạn phát hành phiên bản mới ra thế giới bên ngoài.

Vì vậy, nếu bạn thực hiện một thay đổi lớn chuyển từ phiên bản 1.0.0.0 sang phiên bản 2.0.0.0 (ví dụ bạn đã thay đổi từ WinForms sang WPF). Nếu bạn thực hiện một thay đổi nhỏ hơn, hãy chuyển từ 1.0.0.0 sang 1.1.0.0 (bạn đã thêm hỗ trợ cho các tệp png). Nếu bạn thực hiện một thay đổi nhỏ, hãy chuyển từ 1.0.0.0 sang 1.0.1.0 (bạn đã sửa một số lỗi).

Nếu bạn thực sự muốn nhận chi tiết, hãy sử dụng số cuối cùng làm số bản dựng sẽ tăng cho mỗi lần đăng ký / cam kết (nhưng tôi nghĩ rằng điều đó sẽ đi quá xa).

Tôi sẽ sử dụng x.y.zloại phiên bản

x- phát hành chính - phát hành
ynhỏ
z- xây dựng số

Tôi cơ bản theo mô hình này:

• bắt đầu từ 0.1.0

• Khi nó sẵn sàng, tôi phân nhánh mã trong repo nguồn, gắn thẻ 0.1.0 và tạo nhánh 0.1.0, head / trunk trở thành ảnh chụp nhanh 0.2.0 hoặc một cái gì đó tương tự

• Tôi chỉ thêm các tính năng mới vào trung kế, nhưng backport sửa lỗi cho nhánh và trong thời gian tôi phát hành từ nó 0.1.1, 0.1.2, ...

• Tôi tuyên bố phiên bản 1.0.0 khi sản phẩm được coi là hoàn thành tính năng và không có thiếu sót lớn

• từ đó trở đi - mọi người có thể quyết định khi nào sẽ tăng phiên bản chính ...

Tôi sử dụng quy tắc này cho các ứng dụng của mình:

XYZ

Ở đâu:

• x = số phiên bản chính, 1- ~.
• y = số tính năng, 0-9. Tăng số này nếu thay đổi có các tính năng mới có hoặc không có sửa lỗi.
• z = số hotfix, 0- ~. Tăng số này nếu thay đổi chỉ chứa sửa lỗi.

Thí dụ:

• Đối với ứng dụng mới, số phiên bản bắt đầu bằng 1.0.0.
• Nếu phiên bản mới chỉ chứa các sửa lỗi, hãy tăng số hotfix để số phiên bản sẽ là 1.0.1.
• Nếu phiên bản mới chứa các tính năng mới có hoặc không có sửa lỗi, hãy tăng số tính năng và đặt lại số hotfix thành 0 để số phiên bản sẽ là 1.1.0. Nếu số tính năng đạt 9, hãy tăng số phiên bản chính và đặt lại tính năng và số hotfix thành 0 (2.0.0, v.v.)

Chúng tôi sử dụng abcd ở đâu

• a - chính (tăng khi giao hàng cho khách)
• b - nhỏ (tăng khi giao hàng cho khách)
• c - sửa đổi (tăng trên các bản phát hành nội bộ)
• d - xây dựng (tăng theo điều khiển hành trình)

Một ví dụ khác cho A.B.Ccách tiếp cận là Phiên bản gói của Eclipse . Các gói Eclipse thay vì có một phân đoạn thứ tư:

Trong Eclipse, số phiên bản bao gồm bốn (4) phân đoạn: 3 số nguyên và một chuỗi tương ứng được đặt tên major.minor.service.qualifier. Mỗi phân đoạn nắm bắt một mục đích khác nhau:

• phân đoạn chính biểu thị sự phá vỡ trong API
• phân đoạn nhỏ biểu thị các thay đổi "hiển thị bên ngoài"
• phân đoạn dịch vụ chỉ ra các sửa lỗi và thay đổi luồng phát triển
• phân khúc định tính cho thấy một bản dựng cụ thể

Ngoài ra còn có các chương trình ngày versioning , ví dụ như: YYYY.MM, YY.MM,YYYYMMDD

Nó khá nhiều thông tin vì cái nhìn đầu tiên tạo ấn tượng về ngày phát hành. Nhưng tôi thích sơ đồ xyz hơn, vì tôi luôn muốn biết điểm chính xác của sản phẩm trong vòng đời của nó (Major.minor.release)

Câu trả lời cơ bản là "Nó phụ thuộc".

Mục tiêu của bạn trong phiên bản là gì? Nhiều người sử dụng version.revision.build và chỉ quảng cáo phiên bản.revision ra thế giới vì đó là phiên bản phát hành chứ không phải là phiên bản dev. Nếu bạn sử dụng 'phiên bản' đăng ký thì bạn sẽ nhanh chóng thấy rằng số phiên bản của mình trở nên lớn.

Nếu bạn đang lập kế hoạch cho dự án của mình thì tôi sẽ sửa đổi tăng dần cho các bản phát hành với các thay đổi nhỏ và phiên bản gia tăng cho các bản phát hành có thay đổi lớn, sửa lỗi hoặc chức năng / tính năng. Nếu bạn đang cung cấp các bản phát hành loại bản dựng hoặc bản beta hàng đêm thì hãy mở rộng phiên bản để bao gồm bản dựng và bản tăng dần với mỗi bản phát hành.

Tuy nhiên, vào cuối ngày, điều đó tùy thuộc vào bạn và nó có ý nghĩa với bạn.

Như Mahesh nói: Tôi sẽ sử dụng loại phiên bản xyz

x - bản phát hành chính y - bản phát hành nhỏ z - số bản dựng

bạn có thể muốn thêm một datetime, có thể thay vì z.

Bạn tăng bản phát hành nhỏ khi bạn có bản phát hành khác. Bản phát hành chính có thể sẽ ở mức 0 hoặc 1, bạn thay đổi khi bạn thực sự thay đổi lớn (thường là khi phần mềm của bạn ở điểm không tương thích ngược với các bản phát hành trước hoặc bạn đã thay đổi toàn bộ khung)

Bạn biết bạn luôn có thể kiểm tra xem những gì người khác đang làm. Phần mềm nguồn mở có xu hướng cho phép truy cập vào kho lưu trữ của họ. Ví dụ: bạn có thể trỏ trình duyệt SVN của mình tới http://svn.doctrine-project.org và xem hệ thống phiên bản được sử dụng bởi một dự án thực tế.

Số phiên bản, thẻ, tất cả đều ở đó.

Chúng tôi theo phương pháp abc như:

tăng 'a' nếu có một số thay đổi lớn xảy ra trong ứng dụng. Giống như chúng tôi nâng cấp ứng dụng .NET 1.1 lên .NET 3.5

tăng 'b' nếu có một số thay đổi nhỏ như bất kỳ CR hoặc Cải tiến mới nào được triển khai.

tăng 'c' nếu có một số lỗi sửa lỗi trong mã.

Tôi bắt đầu phiên bản ở mức thấp nhất (không phải hotfix). Tôi không giới hạn phân khúc này xuống 10. Trừ khi bạn đang theo dõi các bản dựng thì bạn chỉ cần quyết định khi nào bạn muốn áp dụng mức tăng. Nếu bạn có pha QA thì đó có thể là nơi bạn áp dụng mức tăng cho phân đoạn thấp nhất và sau đó phân tách tiếp theo khi vượt qua QA và được giải phóng. Để lại phân khúc cao nhất cho các thay đổi hành vi / giao diện người dùng chính.

Nếu bạn giống như tôi, bạn sẽ biến nó thành một phương pháp lai để phù hợp với tốc độ phát triển của phần mềm của bạn.

Tôi nghĩ rằng mẫu abc hoặc abcd được chấp nhận nhiều nhất đặc biệt là nếu bạn có QA / Tuân thủ trong hỗn hợp. Tôi đã có rất nhiều flack xung quanh ngày là một phần thường xuyên của các phiên bản mà tôi đã từ bỏ nó để làm chủ đạo.

Tôi không theo dõi các bản dựng nên tôi thích sử dụng mẫu abc trừ khi có liên quan đến hotfix. Khi tôi phải áp dụng một hotfix thì tôi áp dụng tham số d là ngày theo thời gian. Tôi chấp nhận tham số thời gian là d vì luôn có tiềm năng vài lần trong một ngày khi mọi thứ thực sự bùng nổ trong sản xuất. Tôi chỉ áp dụng phân đoạn d (YYYYMMDDHHNN) khi tôi chuyển hướng để sửa lỗi sản xuất.

Cá nhân tôi sẽ không phản đối sơ đồ phần mềm của va.b revc trong đó c là YYYYMMDDHHMM hoặc YYYYMMDD.

Tất cả những gì đã nói. Nếu bạn chỉ có thể snag một công cụ để cấu hình và chạy với nó sẽ giữ cho bạn khỏi đau đầu phải marshall các khía cạnh ý kiến của versioning và bạn chỉ có thể nói "sử dụng công cụ" ... bởi vì tất cả mọi người trong quá trình phát triển thường rất phù hợp .