Cách thích hợp để sử dụng các phiên bản và mốc quan trọng

Question

Mục đích của các phiên bản và mốc quan trọng trong Trac là gì? Làm thế nào để sử dụng chúng? Điểm mốc khác với phiên bản như thế nào?

Answer 1

Một cách hay để minh họa sự khác biệt là nghĩ về một vé lỗi. Khi bạn nộp vé, bạn (người gửi vé) sử dụng trường phiên bản để cho biết phiên bản phần mềm có lỗi. Khi người bảo trì phần mềm xử lý vé, họ chỉ định nó cho một mốc cho biết khung thời gian mà lỗi sẽ được khắc phục. Vé có thể được chỉ định lại từ cột mốc này đến cột mốc khác tùy theo lịch trình dự án, nhưng số phiên bản vẫn giữ nguyên. Số phiên bản đề cập đến những thứ đã được phát hành và các mốc quan trọng đề cập đến những thứ đang được phát triển hoặc lên kế hoạch cho tương lai và chưa bắt đầu.

Một số dự án có ánh xạ 1: 1 giữa các phiên bản và mốc quan trọng. Ví dụ, bản thân dự án Trac có một mốc quan trọng cho bản phát hành 0.12.3, 0.13, 0.14, v.v. Họ cũng có nhiều mốc lịch sử trừu tượng hơn mà không ánh xạ tới một bản phát hành cụ thể, chẳng hạn như "next-major-0.1X" (cho biết bất kỳ bản phát hành chính tiếp theo nào xảy ra), "không áp dụng" và "không được lên lịch". Tuy nhiên, khi bạn tạo một vé, những thứ duy nhất được liệt kê trong trường "Phiên bản" sẽ được phát hành phiên bản và phiên bản dưới sự phát triển tích cực.

Các mốc quan trọng của bạn không có tương quan với phiên bản của bạn theo bất kỳ cách nào nếu bạn không muốn chúng. Ví dụ: bạn có thể tạo các mốc quan trọng cho "tháng 10 năm 2011", "tháng 11 năm 2011", v.v ... và sử dụng chúng để lên lịch các tác vụ để hoạt động trên mỗi tháng. Nó hoàn toàn tùy thuộc vào bạn và nhu cầu của dự án cụ thể của bạn.

Answer 2

Phiên bản thường là nhiều hơn cho bản phát hành cho người dùng.

Sự kiện quan trọng là nhiều hơn cho các bước cần được hoàn thành trong quá trình phát triển. Người dùng không nhìn thấy hoặc cần phải nhận thức được chúng. Một số cửa hàng dev coi đây là phiên bản phụ (1.3.2a) sẽ được tổng hợp thành phiên bản phát hành (1.3.2).

Có một cuộc thảo luận tốt về điều đó here.

Answer 3

Các workflow đi một cái gì đó như thế này:

• Bạn có vé, có thể được yêu cầu cho các tính năng mới, sửa lỗi, cải tiến, vv
• Sau đó, bạn quyết định vé có ưu tiên cao hơn (dựa trên lẽ những gì người dùng cần hoặc mức độ nghiêm trọng là một bugfix, v.v.).
• Để tổ chức công việc (và nhà phát triển có liên quan), bạn có thể nêu rõ "một mốc quan trọng sẽ kéo dài 2 tuần" (có thể nhiều hơn, ít hơn, tùy thuộc vào bạn)
• Sau đó, bạn có thể ước tính có bao nhiêu vé trong số đó có thể được giải quyết thực sự trong khoảng thời gian đó (1 mốc).
• Sau đó, bạn có thể phát hành phiên bản mới mỗi một số mốc quan trọng (nghĩa là: bản phát hành công khai sau 1 hoặc 2-4 cột mốc, trừ khi điều gì đó quan trọng cần được sửa).

Tóm lại, các phiên bản được dự định là bản phát hành đầy đủ (dù là công cộng hay không). Và các mốc quan trọng là lộ trình cho các phiên bản đó. Vé là đơn vị tối thiểu của công việc có thể được thực hiện trong mỗi một trong những mốc quan trọng đó.