출처:http://trac.tistory.com/12
Trac을 쓰다보면 마일스톤과 버전이 어찌보면 같은 의미같기도 하고, 아닌거 같기도 하고 그렇습니다. 찾아봤더니 다른 분들도 역시나 햇갈려 하시나 봅니다.
Trac의 메일링리스트에서 다음과 같은 글을 찾았습니다.
(출처: http://www.mail-archive.com/trac@lists.edgewall.com/msg01241.html)
- A milestone is created for each future version of the software we intend to release. This includes bug fix releases as well as major planned versions.
- When a bug is found and a ticket is created, we set the version field to the version of our product in which the bug was discovered. This is later updated if the bug was found to have been introduced in an earlier version.
- If a ticket is created for an enhancement or task (i.e. anything other than a bug) then the version field is left empty.
- Periodically I set the milestones of all tickets to be the version (s) in which we expect the bugs to be fixed or features to be introduced.
- When we tag a new release the milestone is marked as completed and we then add the version of the new release to the version list in Trac (so that bugs can be filed against that version). A new milestone is then created for the next release in that branch.
번역을 해보면...
- 마일스톤은 릴리즈하려는 소프트웨어의 미래의 버전마다 만든다. 여기에는 버그수정이나 메이저로 계획한 버전들도 포함된다.
- 버그를 찾아서 티켓을 발행할 때, 버전 필드에는 버그를 찾은 버전으로 선택한다. 만약 이 버그가 더 이전의 버전에서 발견되었다면 나중에 해당 버전으로 업데이트해야 한다.
- 티켓이 개선사항(enhancement)나 할일(task)라면(버그가 아닌 다른 것들이면) 버전 필드는 비어둔다.
- 주기적으로 모든 티켓의 마일 스톤을 해결되거나 나중에 추가될 것으로 예측하는 버전으로 설정한다.
- 새 릴리즈를 태그할 때 마일스톤이 끝난 것으로 하고 버전 목록에 새 릴리즈 버전을 추가한다. (그래야 이 버전에 대해 버그가 발견되면 선택을 할 수 있기 때문이다.) 브랜치에는 다음버전을 위해 다음 릴리즈를 위해 마일스톤을 새로 만든다.
이렇습니다. 댓글메시지에도 나오지만 마일스톤은 "미래"이며, 버전은 "과거"를 의미하네요.
결론적으로 보면 버전의 항목들과 마일스톤의 항목들은 버전 형식("1.0", "1.1.1.1" 등)과 같이 되겠더군요. 사실 지금은 다르게 해 놓고 썼거든요.
반드시 이렇게 써야 하는건 아니겠지만, 이렇게 쓰게 되면 좀 더 전달이 잘 될 듯 합니다.
도움이 되시길...
Trac을 쓰다보면 마일스톤과 버전이 어찌보면 같은 의미같기도 하고, 아닌거 같기도 하고 그렇습니다. 찾아봤더니 다른 분들도 역시나 햇갈려 하시나 봅니다.
Trac의 메일링리스트에서 다음과 같은 글을 찾았습니다.
(출처: http://www.mail-archive.com/trac@lists.edgewall.com/msg01241.html)
- A milestone is created for each future version of the software we intend to release. This includes bug fix releases as well as major planned versions.
- When a bug is found and a ticket is created, we set the version field to the version of our product in which the bug was discovered. This is later updated if the bug was found to have been introduced in an earlier version.
- If a ticket is created for an enhancement or task (i.e. anything other than a bug) then the version field is left empty.
- Periodically I set the milestones of all tickets to be the version (s) in which we expect the bugs to be fixed or features to be introduced.
- When we tag a new release the milestone is marked as completed and we then add the version of the new release to the version list in Trac (so that bugs can be filed against that version). A new milestone is then created for the next release in that branch.
번역을 해보면...
- 마일스톤은 릴리즈하려는 소프트웨어의 미래의 버전마다 만든다. 여기에는 버그수정이나 메이저로 계획한 버전들도 포함된다.
- 버그를 찾아서 티켓을 발행할 때, 버전 필드에는 버그를 찾은 버전으로 선택한다. 만약 이 버그가 더 이전의 버전에서 발견되었다면 나중에 해당 버전으로 업데이트해야 한다.
- 티켓이 개선사항(enhancement)나 할일(task)라면(버그가 아닌 다른 것들이면) 버전 필드는 비어둔다.
- 주기적으로 모든 티켓의 마일 스톤을 해결되거나 나중에 추가될 것으로 예측하는 버전으로 설정한다.
- 새 릴리즈를 태그할 때 마일스톤이 끝난 것으로 하고 버전 목록에 새 릴리즈 버전을 추가한다. (그래야 이 버전에 대해 버그가 발견되면 선택을 할 수 있기 때문이다.) 브랜치에는 다음버전을 위해 다음 릴리즈를 위해 마일스톤을 새로 만든다.
이렇습니다. 댓글메시지에도 나오지만 마일스톤은 "미래"이며, 버전은 "과거"를 의미하네요.
결론적으로 보면 버전의 항목들과 마일스톤의 항목들은 버전 형식("1.0", "1.1.1.1" 등)과 같이 되겠더군요. 사실 지금은 다르게 해 놓고 썼거든요.
반드시 이렇게 써야 하는건 아니겠지만, 이렇게 쓰게 되면 좀 더 전달이 잘 될 듯 합니다.
도움이 되시길...
'개발자 기본 소양' 카테고리의 다른 글
Trac 설치하기 (0) | 2009.02.11 |
---|---|
[TRAC] Admin 추가 방법 (0) | 2009.02.08 |
[TRAC] ticket properties 추가 및 삭제 (0) | 2009.02.07 |
DRM (0) | 2009.02.04 |
NAND에 관하여 (0) | 2009.01.16 |