소스 버전 관리에서 릴리스 브랜치는 어떤 정책으로 만드시나요?

저는 패키지 판매 형태가 아닌, 서비스 제공이 주력 사업인 회사에서 개발을 하고 있습니다. 그래서 개발한 프로그램을 내부적으로만 릴리스하고 외부로 배포하는 경우는 없습니다. 사실 내부 릴리스라고 보기도 좀 뭐하고 그냥 버전 올라가면 제가 설치해주곤 합니다. 그래도 개인적으로는 CVS를 사용해서 릴리스 브랜치 관리를 하고 있습니다.

저는 프로젝트의 메인 트렁크는 항상 마지막 릴리스 상태로 유지를 합니다. 그래서 체크아웃할 때 따로 태그나 브랜치를 지정하지 않고 그냥 헤드를 체크아웃 했을 때 stable version을 받을 수 있도록 하고 있습니다. 그리고 새로운 버전 릴리스와 동시에 버전 번호로 릴리스 브랜치를 생성해서 추후 발생하는 수정이나 기능 추가는 모두 해당 브랜치에서만 작업을 합니다. 나중에 어느 정도 변경이 모였을 때 다시 릴리스를 하고, 이 때 릴리스 브랜치의 수정 사항을 메인 트렁크에 병합 시킵니다. 그리고나서 다시 릴리스 버전 번호로 브랜치를 만들고 위 과정을 반복하고요.

그림으로 그리면 간단한데 글로 적으니 좀 복잡하군요. 아무튼 제 방식의 요지는 HEAD를 체크아웃하면 항상 안정 버전을 받을 수 있도록 하는것입니다. 그런데 버전 관리 책을 보니 저와 반대로 운영을 하는게 바람직한 방식이라고 되어 있군요. 메인 트렁크에서 계속 개발을 하고 릴리스 브랜치는 해당 릴리스의 버그 수정만하고 그것을 메인 트렁크에 병합 시키는 방식으로요. 이건 소프트웨어를 외부로 배포하는 기업을 기준으로 설명한거겠죠?

그래서 다른 분들은 어떤 방법으로 릴리스 브랜치를 관리하는지 궁금하네요. 그리고 혹시 제가 사용하는 방법에 문제가 있다면 지적도 부탁드립니다.