종속 소프트웨어 구성 요소의 버전 번호 지정에 대한 모범 사례를 찾고

서로 다른 소프트웨어 구성 요소의 버전 번호를 매길 수있는 좋은 방법을 결정하려고합니다.

좀 더 구체적으로합시다 :

소프트웨어 구성 요소 A는 내장 장치에서 실행되는 펌웨어이고 구성 요소 B는 일반 PC (Linux / Windows 시스템) 용 해당 드라이버입니다. 그들은 사용자 정의 프로토콜을 사용하여 서로 통신하고 있습니다. 당사의 제품은 개발자를 대상으로하기 때문에 두 구성 요소의 안정적이고 불안정한 (실험적) 버전을 제공합니다 (펌웨어는 비공개 소스이고 드라이버는 공개 소스입니다). 가장 큰 어려움은 통신 프로토콜에서 API 변경을 처리하는 방법입니다.

드라이버에서 호환성 검사를 구현하는 동안 (펌웨어 버전이 드라이버 버전과 호환되는지 확인) 여러 가지 버전 번호 지정 방법에 대해 논의하기 시작했습니다.

우리는 하나의 해결책을 생각해 냈지만, 바퀴를 재창조하는 것처럼 느꼈습니다. 이것이 일반적인 문제라고 생각하기 때문에 프로그래머 / 소프트웨어 개발자 커뮤니티로부터 피드백을 받고 싶습니다.

그래서 우리의 해결책은 다음과 같습니다.

널리 사용되는 major.minor.patch 버전 번호 를 따르고 안정 / 불안정 버전에 짝수 / 홀수 부 번호를 사용할 계획 입니다. API에 변경 사항을 도입하면 부수가 증가합니다.

이 컨벤션은 다음 예제 상황으로 이어질 것입니다.

현재 안정 분기는 1.2.1이고 불안정은 1.3.7입니다. 이제 불안정한 새 패치로 API가 변경되어 불안정한 새 버전 번호가 1.5.0이됩니다. 일단 불안정한 브랜치가 안정적인 것으로 간주되면 1.5.3에서 1.4.0으로 릴리스 할 것입니다.

아래 관련 질문에 대한 답변에 대해 기쁘게 생각합니다.

• 위에서 설명한 문제를 처리하기위한 모범 사례를 제안 할 수 있습니까?
• "맞춤형"컨벤션이 좋다고 생각하십니까?
• 설명 된 규칙에 어떤 변경 사항을 적용 하시겠습니까?

IMHO 버전 번호는 제품 이름과 같습니다. 내용보다는 장식이라는 점에서 중요하지만 중요하지 않다는 점에서 중요합니다.

제품 이름과 같은 버전 번호는 여전히 의미가 있습니다. 그리고 가장 중요한 것은 혼란을 피하는 것입니다. 버전 번호와 관련하여 일반적으로 기대되는 사항은 다음 과 같습니다. 이러한 예외가 충족되지 않으면 사용자는 혼란 스러울 것입니다.

버전 번호는 단조 증가합니다.
이것은 아마도 가장 명백한 기대 일뿐 아니라 실제로는 사실 일 가능성이 가장 낮습니다. 한 눈에 사용자는 버전 2.3.5가 버전 2.2.17 이후에 올 것으로 예상 하고 동일하거나 더 나은 기술을 보유 할 것으로 예상합니다 . 그러나 물론 2.3.x는 개발 브랜치이며 2.2.x는 안정적 이며 2.3.5는 2004 년에 실제로 릴리스되었으며 2.2 브랜치는 여전히 활발히 작업 중이며 2.2.17은 지난 4 월에 릴리스되어 포함되어 있습니다. .. 글쎄, 당신은 아이디어를 얻는다. 숫자가 가진 모든 의미에 대해 버전 2.2 "Potato"를 호출 할 수도 있습니다. " Potato-17 " 버전에 오신 것을 환영합니다 !

비슷한 버전으로 업그레이드 가능 / 호환 가능
컴퓨터에 버전 3.7이 있고 3.8이 새로운 반짝이는 frozbot과 함께 나오는 경우 업그레이드 나 패치 등으로 3.7이 중단없이 3.8이 될 것으로 기대합니다. 그러나 3.7에 있고 5.2를 릴리스하면 그렇게 낙관적이지 않습니다. 물론, 나는 실망하기보다는 오히려 즐겁게 놀랐습니다.

첫 번째 숫자는 중요
합니다 .Java가 그 문제에 대해 너무 혼란스럽지 않은 경우 이것을 언급하지 않아도됩니다. 누군가가 말하지 않으면 "Java 7"이 실제로 버전 1.7이라고 기대하지 않을 것입니다. 그리고 당신이 이것을 처음 들었을 때, 당신은 거의 확실하게 대답했습니다 : " 무엇? .. 왜? "

플랫폼 변경이 이전 버전과 호환되지 않는 경우에만 주 버전 번호가 변경 될 것입니다. 하지만 실제로는 이전 버전과의 호환성 드롭 할 계획입니까 이제까지 ? 종종 메이저 버전 개정판은 기술적 결정이 아닌 마케팅 결정입니다. 자바 터무니없는 행동은 동시에 두 캠프 모두에서 거의 코믹한 영향을 미칩니다.

마지막으로
방금 언급했듯이 버전 번호는 종종 기술에 관한 것만 큼 마케팅에 관한 것입니다. 버전 번호가 어떤 것이기 때문에 괜찮습니다. 소프트웨어의 새로운 기능을 한 눈에 알 수 있습니다. 큰 숫자 변경은 큰 기능 변경을 의미합니다. 작은 숫자 변경은 거의 기능 변경이 없음을 의미합니다. 그것이 사람들이 기대하는 것 입니다. 참인지 여부는 버전 번호가 사용자가 생각하는 것과 동일한 의미를 갖는지 여부를 결정합니다.

-편집-
나는 이것을 언급하는 것을 잊었지만 Caleb 은 그것을 잘 지적했습니다. 다른 곳에서 명시 적으로 만들지 않고 중요한 (예 : 안정 / 불안정) 것을 나타 내기 위해 버전 번호를 사용하지 마십시오. 예, 당신은 이상한 마이너 버전 번호가 개발을 나타냅니다 것을 알고,하지만 우리 중 하나 있습니다. 데비안의 "불안정한"릴리즈 모니 커가 좋은 예입니다. 또는 완전히 별개의 제품 이름을 사용할 수도 있습니다. 제품 이름은 "Frozbot 1.2", 개발 버전은 "Devbot 1.3"입니다.

일단 불안정한 브랜치가 안정적인 것으로 간주되면 1.5.3에서 1.4.0으로 릴리스 할 것입니다.

아니 아니. 불안정한 1.5.3 안정의 경우 1.6.0부터 시작해야합니다 (시맨틱 버전 관리를 사용하지 않으려는 경우 1.4.x는 누락되었습니다)

하나의 값을 사용하여 두 가지 별도의 것을 나타냅니다.

먼저, "버전"이 있습니다. 일반적으로 다양한 릴리스를 식별하고 릴리스 순서를 나타냅니다. tylerl이 말했듯이 버전은 항상 증가해야합니다. 버전을 1.5.3에서 1.4.0으로 변경하면 사용자에게 의미가 없으며 내부 혼란도 많이 발생할 수 있습니다.

둘째, 주어진 버전이 안정적인지 여부를 나타냅니다.

그것은이다 가능한 일부 점포는 항목이 판매 여부를 나타 내기 위해 약간의 가격 책정 방식을 사용하는 것처럼 "버전 번호"하나에 두 가지를 나타냅니다. 예를 들어, 가까운 매장에서 '3'으로 끝나는 가격은 최종 판매 가격입니다. 이는 판매가를 파악하는 방법을 빨리 배우는 직원에게는 효과적이지만 고객에게 판매에 대해 알리는 좋은 방법은 아닙니다. 따라서 판매 품목 근처에 표지판을 표시했습니다. 안정적인 릴리스를 위해 가장 작은 자릿수를 만들고 실험 릴리스를 위해 홀수를 만드는 것과 같은 유사한 작업을 수행 할 수 있습니다. 하지만 실험적인 것을 발표 할 때는 분명히 그렇게 표시해야한다고 생각합니다. 다음과 같이 버전 문자열의 시작 또는 끝에 'X'를 추가 할 수 있습니다.X.1.5.31.5.3.X. 그 후 실험 버전 번호를 사용할 수도 있으므로 동일한 기본 버전 인 1.5.3.X1,을 기반으로 여러 실험 버전을 모두 릴리스 할 수 1.5.3.X2있습니다.

또한 "알파"및 "베타"버전 번호 를 사용하여 안정적이거나 완전하지 않을 수있는 버전을 나타내는 오랜 전통이 있음을 고려해야합니다1.5.3a54 . 다른 작업을하기로 결정한 경우 개발자 커뮤니티에 다른 것을 설명해야하기 때문에이 계획을 벗어나야 할 합당한 이유가 있는지 확인하십시오.

안정된 / 불안정한 버전의 경우 확장명 "tag"를 사용하고 major 및 minor 숫자의 명확한 의미를 사용하여 major.minor.patch 형식을 사용하는 것이 좋습니다.

major.minor.patch-stable|unstable

어디

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

이러한 방식으로 종속성을 쉽게 관리 할 수 ​​있으며 각 구성 요소 클라이언트 / 사용자에게 새 버전에 더주의를 기울여야 할 때 알릴 수 있습니다. 예를 들어, 성분 A (1.1.0- 안정)가 B (5.4.534- 안정)에 의존하고 새로운 버전의 B가 예정되어 있다면 (6.1.0- 안정적) A가 변경되어야한다는 것을 즉시 인식 할 수 있습니다. .

나는 Hibernating Rhinos가 RavenDb를 vis-a-vis 버전으로 구축하는 방식을 정말 좋아합니다. 빌드 수가 계속 증가하고 있습니다. 그들이 안정을 얻으면 안정으로 표시됩니다. 그러나 모든 것이 릴리스 후보입니다.