Właściwy sposób używania wersji i kamieni milowych

Question

Jaki jest zamierzony cel wersji i kamieni milowych w Trac? Jak z nich korzystać? Czym różni się kamień milowy od wersji?

Answer 1

Dobrym sposobem na zilustrowanie różnicy jest wymyślenie biletu na wady. Podczas zgłaszania biletu, użytkownik (zgłaszający bilet) używa pola wersja do wskazania wersji oprogramowania, która wykazuje wadę. Po tym, jak opiekun oprogramowania dokona segregacji biletu, przypisuje go do etapu kamień milowy, który wskazuje ramy czasowe, w których defekt zostanie naprawiony. Bilet może zostać ponownie przydzielony z jednego etapu do drugiego w zależności od harmonogramu projektu, ale numer wersji pozostanie taki sam. Numery wersji odnoszą się do rzeczy, które zostały już wydane, a kamienie milowe odnoszą się do rzeczy, które są opracowywane lub planowane na przyszłość i jeszcze się nie rozpoczęły.

Niektóre projekty mają odwzorowanie 1: 1 między wersjami i kamieniami milowymi. Na przykład sam projekt Trac ma kamień milowy w wydaniach 0.12.3, 0.13, 0.14 itd. Mają też bardziej abstrakcyjne kamienie milowe, które nie są mapowane do konkretnego wydania, takie jak "next-major-0.1X" (który wskazuje, co będzie następnym ważnym wydaniem), "nie dotyczy" i "nieplanowane". Jednak kiedy idziesz do stworzenia biletu, jedynymi rzeczami wymienionymi w polu "Wersja" są wydane wersje i wersje pod aktywnym rozwojem.

Twoje kamienie milowe nie mają korelować ze swoimi wersjami w żaden sposób, jeśli nie chcesz ich. Możesz na przykład utworzyć kamienie milowe na "październik 2011", "listopad 2011" itd. I używać ich do planowania zadań do wykonania w każdym miesiącu. To zależy od ciebie i od potrzeb twojego konkretnego projektu.

Answer 2

Wersje generalnie są bardziej przeznaczone do wydania użytkownikom.

Kamienie milowe to więcej kroków, które należy wykonać w fazie rozwoju. Użytkownicy nie widzą ani nie muszą ich znać. Niektóre sklepy internetowe traktują je jako podwersje (1.3.2a), które zostaną zsumowane do wersji zwolnionej (1.3.2).

Istnieje dobra dyskusja na ten temat: here.

Answer 3

Workflow wychodzi coś takiego:

• Masz bilety, które mogą być wnioski o nowe funkcje, poprawki błędów, ulepszenia, itp
• Następnie należy zdecydować, które bilety mają wyższy priorytet (na podstawie może czego potrzebują użytkownicy lub jak ważna jest poprawka, itp.).
• Aby zorganizować pracę (i zaangażowanych programistów), możesz podać coś w stylu "kamień milowy będzie miał 2 tygodnie" (może być więcej, może być mniej, to zależy od ciebie).
• Następnie możesz oszacować ile z tych biletów można rzeczywiście rozwiązać w tym czasie (1 kamień milowy).
• Następnie można wydać nową wersję co kilka kamieni milowych (tj. Publiczne wydanie po 1 lub 2-4 etapach, chyba że trzeba coś krytycznego naprawić).

Podsumowując, wersje mają być pełnymi wersjami roboczymi (publicznymi lub nie). I kamienie milowe są mapą drogową do tych wersji. Bilety są minimalną jednostką pracy, którą można wykonać w każdym z tych kamieni milowych.