Khi nào tôi nên tăng số phiên bản?

Tôi đã không học lập trình ở trường và tôi không làm việc như một nhà phát triển (chuyên nghiệp), do đó rất nhiều điều cơ bản không rõ ràng đối với tôi. Câu hỏi này cố gắng làm rõ một trong số họ.

Bây giờ chúng ta hãy giả sử rằng tôi có vấn đề #1, #2và #3trong vấn đề Tracker của tôi được thiết lập để được sửa chữa / tăng cường cho phiên bản 1.0.0và rằng (ổn định) phiên bản cuối cùng là 0.9.0.

Khi nào tôi nên tăng lên phiên bản 1.0.0? Khi a) chỉ một trong những vấn đề được liệt kê ở trên bị đóng hoặc b) khi tất cả các vấn đề liên quan đến phiên bản 1.0bị đóng?

Cái nào là đúng cách để làm điều đó? Và theo đúng cách, tôi có nghĩa là những gì hiện đang được sử dụng trong ngành công nghiệp.

Tôi có thể cho bạn biết làm thế nào tôi làm điều đó trong công việc.

Chúng tôi có một máy chủ tích hợp liên tục để xây dựng, kiểm tra, gắn thẻ và xuất ra một gói phiên bản. Chúng tôi chỉ tiến hành giai đoạn tiếp theo nếu giai đoạn trước là% 100 thành công.

Phiên bản của chúng tôi trông như thế này: <Phiên bản chính>. <Phiên bản nhỏ>. <Số bản dựng>

• Mỗi bản dựng thành công không có sửa lỗi hoàn chỉnh hoặc cải tiến tính năng sẽ tăng Số bản dựng.
• Mỗi bản dựng thành công với bản sửa lỗi hoàn chỉnh hoặc cải tiến tính năng sẽ tăng Phiên bản nhỏ. Điều này được tự động phát hiện bởi sự hiện diện của một thông điệp cam kết sử dụng một định dạng cụ thể. Thông báo cam kết này cũng tự động được kéo vào các dự án ChangeLog.
• Mỗi gia tăng Phiên bản chính được thực hiện bằng tay khi chúng tôi có các thay đổi không tương thích ngược, viết lại từ đầu hoặc các lý do khác được thực hiện trên cơ sở từng trường hợp.

Số phiên bản chỉ có liên quan đến các bản phát hành , vì chúng là cách để người dùng bên ngoài xác định bản dựng cụ thể của phần mềm của bạn. Nếu bạn chỉ bận thực hiện phát triển và không phát hành từng bản sửa lỗi, thì đừng lo lắng về việc tăng số lượng phát hành cho mỗi bản sửa lỗi. Nó không liên quan đến người dùng bên ngoài và lãng phí thời gian của bạn với sổ sách phiên bản bổ sung.

Đối với các ứng dụng web được triển khai liên tục, chúng tôi có xu hướng xây dựng các số xây dựng bằng cách sử dụng bộ cộng hưởng phía trước và đuôi số xây dựng, tức là: 2.5.3.4328 trong đó 4328 đến từ hệ thống tích hợp liên tục. Kỳ vọng chung là số lượng thay đổi theo các bước có chủ ý nhưng số bản dựng là ID duy nhất thực sự.

Những gì nó dường như đang làm ở đây là ghi lại ngày triển khai và số bản dựng svn liên quan:

        <div id="svnrev">
            rev 2013.10.21.1078
        </div>

Cho những gì nó có giá trị.

Các câu trả lời khác đã rất hay, vì vậy tôi sẽ chỉ thêm vào đầu chúng. Nếu phần mềm của bạn không được phát hành và bạn không thực sự cần phiên bản công khai (phiên bản không công khai là VCS của bạn), thì hãy thêm từ khóa " SNAPSHOT " vào cuối phiên bản của bạn. Một số hệ thống, đặc biệt là trong quản lý phụ thuộc, xử lý các ảnh chụp nhanh khác với các phiên bản được phát hành ở chỗ chúng so sánh ngày thay đổi của các ảnh chụp nhanh thay vì số phiên bản. Vì vậy, nếu bạn đã có phiên bản 1.0.0-SNAPSHOT từ 8 giờ sáng trong gói repo và trình tải xuống phụ thuộc cục bộ có cùng phiên bản từ 7 giờ sáng, nó sẽ tải xuống bản cập nhật từ repo.

Như đã nói ở trên, phiên bản riêng của bạn được cung cấp bởi hệ thống kiểm soát phiên bản của bạn (git, svn, v.v.).

Có đủ nói về lý thuyết phiên bản ở đây là một quan điểm khác.

Khi nào tôi nên tăng lên phiên bản 1.0.0?

Tôi sẽ tập trung câu trả lời của mình vào việc thay đổi số phiên bản chính.

Câu trả lời của tôi là: Về cơ bản khi bạn đã sẵn sàng cho nó. Đi từ 0,9 đến 1 là một điều lớn, bởi vì nhận thức của công chúng sẽ là bạn đang đi từ một sản phẩm beta đến một bản phát hành chính thức.

(Tôi sẽ giả sử ở đây nó là một sản phẩm thương mại từ một công ty).

Một vài câu hỏi trước khi đi từ 0.9 đến 1.0.

Tổ chức của bạn có thời gian để thông báo cho tất cả khách hàng hiện tại của bạn. Để ném một bữa tiệc. Nhận được rất nhiều yêu cầu hỗ trợ. Một người quản lý tài khoản để bán sản phẩm của bạn? Vân vân.

Có, tôi thấy phiên bản là một công cụ tiếp thị và nếu bạn nhìn xung quanh bạn sẽ thấy rằng về cơ bản đó là tiêu chuẩn công nghiệp.

Công ty chúng tôi đã chuyển từ phiên bản 2.x lên 3.0 và có một bữa tiệc tuyệt vời, tạo ra nhiều tiếng vang và vì điều đó có khá nhiều khách hàng mới. Ngoài một số cập nhật giao diện, sự khác biệt giữa các phiên bản là khá nhỏ.