업데이트 버전은 실제로 무엇을 의미합니까?

18

많은 소프트웨어 업데이트는 v0.1 ~ v0.2 ~ v2.6.5.6 의 체계를 따릅니다 . 소프트웨어에 대한 이러한 "업데이트"는 실제로 무엇을 의미합니까? 업계 표준이 항상 준수됩니까? 아니면 프로그래머가 업데이트 번호를 올리거나 소수를 더 추가합니까?

deployment software-updates software-distribution

— 제임스 메르 츠
소스

12

@ S.Lott 프로그래밍 장면에 익숙하지 않아서 특이성을 모를 것입니다. 이것이 내가 생각해 낼 수있는 가장 좋은 방법입니다.

— 제임스 메르 츠

9

@ S.Lott, 카페인 선생님을 줄이면 과민 반응을 보입니다.

— ocodo

2

@ S.Lott는 질문을 더 잘 맞추기 위해 자유롭게 편집하십시오. 내가 찾고있는 것을 알고 있다고 생각합니다. 그러나 제공된 답변이 매우 훌륭하다고 생각합니다. 나는 또한 이전 의견에 대한 유권자들의 판단에 따라 내가 할 수있는 최선을 다했으며 그 질문에 대한 답은 그대로 있다고 생각한다. 그러나 편집뿐만 아니라 비판도 환영합니다. 당신이 적합하다고 생각하는대로하십시오. 나를 위해, 나는 그것을 내버려두고 있습니다.

— James Mertz

1

@ S.Lott 질문은 나에게있는 것처럼 보입니다. 특정 표준 작성 조직을 나열하는 것이 크게 개선되지는 않을 것이라고 생각합니다. 다른 느낌이 든다면 자유롭게 편집하십시오. 당신은 그것에 대한 담당자가 있습니다.

— Adam Lear

3

@ S.Lott : "업계 표준이 있습니까?"는 완벽합니다. 예, 업계 표준이 있습니다! 누가 쓰는지는 중요하지 않습니다. KronoS는 어떤 버전이 어떤 의미인지 알고 싶어합니다. 자세한 내용을 지정하는 것이 그의 선택입니다. 아마도 질문을 광범위하게 생각한다고 언급했을 것입니다. 세부 사항을 망치는 것만으로도 사용자에게 명확하지 않으며 사용자에게 정의하도록 지시합니다.

— Tamara Wijsman

16

Shaun이 말했듯이 실제로 표준은 없습니다. 어떤 회사는 다른 회사보다 더 나은 버전 관리 방법을 가지고 있습니다 (주요 버전 번호를 건너 뛰는 공급 업체와 여러 x 나중에 동일한 xy에 붙어있는 업체를 처리했습니다).

Gravatars의 발명가이자 GitHub의 공동 설립자 ( Tom Preston-Werner ) 는 읽을 가치가있는 ' Semantic Versioning '에 대한 문서를 작성했습니다 .

소개를 제외한 내용은 다음과 같습니다.

이 문제에 대한 해결책으로, 버전 번호를 지정하고 증가시키는 방법을 지시하는 간단한 규칙 및 요구 사항을 제안합니다. 이 시스템이 작동하려면 먼저 공개 API를 선언해야합니다. 이것은 문서로 구성되거나 코드 자체에 의해 시행 될 수 있습니다. 어쨌든이 API는 명확하고 정확해야합니다. 퍼블릭 API를 식별 한 후에는 버전 번호를 특정 단위로 변경하여 변경 사항을 전달합니다. XYZ (Major.Minor.Patch)의 버전 형식을 고려하십시오. API에 영향을 미치지 않는 버그 수정은 패치 버전을 증가시키고 이전 버전과 호환되는 API 추가 / 변경은 부 버전을 증가시키고 하위 버전과 호환되지 않는 API 변경은 주 버전을 증가시킵니다.

이 시스템을 "시맨틱 버전 관리"라고합니다. 이 체계에서 버전 번호와 변경 방법은 기본 코드와 한 버전에서 다음 버전으로 수정 된 내용에 대한 의미를 전달합니다.

— 댄 맥그래스
소스

7

4 자리 숫자는 일반적으로 MajorV.MinorV.PatchNum.BuildNum이며 적어도 내가 일하는 곳입니다.

나는 개인적으로 우분투의 버전 관리 체계를 선호합니다-인생을 훨씬 쉽게 만듭니다.

— 일
소스

그들의 계획은 무엇입니까? 왜 그들을 선호합니까?

— 제임스 메르 츠

3

우분투 10.10 = 2010 년 10 월, 우분투 10.04 = 2010 년 4 월, 우분투 11.04 = 2011 년 4 월, 우분투 9.10 = 2009 년 10 월 등. 이것은 Wikipedia 링크에서 Shaun이 언급 한 것입니다.

— 직업

2

버전 번호로 날짜를 사용하는 것에 대한 좋은 점은 일부 역설적 인 역설이 발생하지 않는 한 버전 번호는 항상 올바른 순서입니다. 우리 대부분은 새 릴리스의 버전을 파악하는 것보다 오늘이 2011.02.13이라는 것을 기억하는 것이 더 쉽습니다.

— jmort253

@ jmort245, 맞아! 인공 시스템은 상당히 지저분합니다. 사기 은행은 일년에 360, 362, 365, 366 등이 있다고 생각합니다. 버전 관리 시스템은 이러한 어리석은 작품 중 하나입니다. 20050207이 502보다 읽고 읽는 데 시간이 조금 더 걸리지 만 타임 스탬프는 생각하지 않습니다. 한 달에 한 번 이상 어떤 소프트웨어가 출시됩니까?

— 직업

2

@job : 그러나 버전을 사용하면 기능을 특정 메이저 또는 마이너 버전에 연결할 수 있습니다. 따라서 버전 2가 있으면 기능 X가 있고 버전 1에는 버전 X가 없습니다.

— Martin York

6

짧은 버전은 표준이 없으며 회사가 원하는 것을 수행한다는 것입니다. 기본적으로 숫자가 많을수록 각 숫자가 나타내는 변화량이 적습니다. 일반적으로 x의 xa 변경은 주요 릴리스 (주요 향상 / 기능 롤아웃)를 나타내고 y는 부 릴리스 (주요 조정 또는 결함 수정)를 나타냅니다. 이 두 개 이후의 소수점 이하 자릿수는 회사 내부에서 다른 것을 의미 할 수 있지만 종종 더 빠르고 작은 수정을 나타내는 작은 컨텐츠 빌드 또는 패치를 중심으로 진행됩니다.

Wikipedia에는 이를 자세히 설명 하는 기사 가 있습니다.

— 숀
소스

3

버전 번호의 목적은 문제 보고서에 대한 참조를 제공하는 것입니다. 유일한 요구 사항은 모든 릴리스에 고유 한 버전 번호가 있어야한다는 것입니다. 일부 숫자는 마케팅에 의해 결정됩니다. 더 큰 정수는 판매하기 쉬우 며 10과 같은 거듭 제곱 (로마 숫자 X)은 실제로 잘 들립니다. 어떤 사람들은 시맨틱 버저 닝의 변형을 사용합니다 :

주요 미사 마이크로 빌드

주요 증분 : 호환되지 않는 변경 사항 또는 UI의 완전한 재 설계
작은 증분 : 새로운 주요 기능 추가, 동일한 주요 버전 번호의 이전 버전과 호환
마이크로 증분 : 버그 수정 릴리스
빌드 번호 : 컴파일러에 의해 생성되거나 버전 제어에서 가져옴

많은 그룹이 릴리스에서 빌드 번호를 삭제합니다. 일반적으로 테스트 그룹과 개발 그룹간에 만 유용합니다.

홀수 번호 MINOR 증분은 실험 빌드 용이고 짝수 번호 MINOR 증분은 프로덕션 릴리스에 대한 것과 같은 추가 의미론을 추가하는 그룹도 있습니다 ( Linux 커널 은이 방법을 사용함).

결론은 표준이 없으며 최신 버전 외에는 더 높은 버전 번호를 사용하며 각 버전 번호는 고유하다는 것입니다.

— 베린 로리 치
소스