참조 : http://en.wikipedia.org/wiki/Software_release_life_cycle
소프트웨어 릴리즈 라이프 사이클에 대한 좋은 글은 많다. 이미 체계도 많이 잡혀져 있다. 다만, 개인적으로 약식 버전을 사용하는데 이에 대한 정리를 해본다. 참조에도 나온 소프트웨어 릴리즈 라이프 사이클에서 나는 아래와 같은 단계정도만 사용한다.
- Alpha > Beta > Release Candidate > Release
이중에 Release Candidate까지는 개발 단계이고, Release는 공개된 단계이다. 이를 안드로이드 어플리케이션에서 버전으로 사용할 때는 a,b,c를 꼬리표로 붙인다. 그 예는 다음과 같다.
2.00.11 버전을 내놓고 싶다면,
- Alpha 버전 : 개발 팀 내부 버전
예) 2.00.11a - Beta 버전 : 사내 검증 받는 버전
예) 2.00.11b - Release Candidate 버전 : 사내 검증이 완료된 버전
예) 2.00.11c - Release 버전 : 사용자에게 공개된 버전
예) 2.00.11
그리고, 개발 팀 내부 버전이나 사내 검증에서 수정사항이 생겨서 버전을 변경해야 한다면 다음과 같이한다. 주로 사내 검증을 받는 경우에 작은 업데이트가 많이 발생하는데,
2.00.11b > 2.00.11b2 > 2.00.11b3 ...
나 같은 경우에는 서비스 어플리케이션을 만들기 때문에 Release가 O/S나 컴파일러 수준으로 부담이 되지 않는다. 그리고 어플리케이션이 실행되기 전에 업데이트 체크도 진행하고 있다. 그래서 Release 버전을 한 단계로하고, 문제가 생기면 내부적 검증을 통해 추가적으로 Release하는 방식으로 관리한다.
애플과 같은 경우 iOS를 내놓을 경우에는 GA나 GM(?)같은 release 단계에서도 버전을 따로 붙이면서 테스트를 계속 하는데, 개인적으로 방법론이란 관련자들과 혼란과 불편을 줄이는 것에 목적이 있는 것이지 따르는 그 자체에 의미가 있는 것이라고 생각하지 않기 때문에 하고 있는 프로젝트에 따라 맞체 커스터마이징할 수 있다고 생각한다. 다만, 괜히 같은 의미를 좀더 멋지다는 이유로 이름을 바꾼다거나 하여 같은 방법론을 쓰는 사람들끼리 혼란을 일으킬 필요는 없겠다.
내게 그런 경험이 있는데 전에 내가 스레드-풀 디자인 패턴이나 워커 스레드 패턴등에서 사용되는 worker라는 단어를 miner같은 것으로 임의대로 변경한 경우가 있었는데, 기능은 같고 개인적인 취향으로 이름을 바꾼 것이라 혼란을 일으켰던 적이 있었다.