소프트웨어 버전 번호 날짜

소프트웨어 개발자는 일반적으로 날짜를 버전 번호로 사용하지 않지만 YYYYMMDD 형식 (또는 그 차이)은 사용할 정도로 견고합니다. 그 계획에 문제가 있습니까? 아니면 제한된 '유형'소프트웨어 (사내 제작과 같은)에만 적용됩니까?

이것은 소프트웨어와 개발자의 요구뿐만 아니라 사용자 요구를 고려해야 할 때 몇 가지 다른 각도에서 살펴 봐야 할 것입니다.

일반적으로 고객은 최신 버전 (예 : Product 2012가 Product 2010보다 최신 제품)을 실행하고 있다는 사실을 알고있는 한 소프트웨어 버전 번호에 대해 크게 신경 쓰지 않습니다. 배포 할 수있는 패치 (예 : 제품 2012, 업데이트 10)가있는 경우 최신 상태입니다. 따라서, 고객 브랜딩 관점에서 볼 때 저는 사용자가 설치할 수있는 엄격한 순서의 패치를 따르는 명명 된 릴리스 (예 : Windows XP, Windows Vista)를 선호합니다.

그러나 사용자가 쉽게 확인할 수있는 소프트웨어를 작성하면 코드 아래의 코드를 작성하기가 훨씬 더 어려워집니다. 따라서 Major.Minor간단한 숫자 비교를 통해 다음과 같이 최신 정보가 있는지 확인할 수 있기 때문에 간단한 버전 체계 를 선호합니다 .

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

그래도 약간의 맥락 에서이 작업을 수행하기 위해 일반적으로 위의 시스템이 계속 성공적으로 실행될 수 있도록 부 번호가 얼마나 큰지 (예 : 1.1024) 상관하지 않습니다. 일반적으로 개정 번호는 내부 개발에만 관심이 있으며 실제로 추적 번호를 추가하는 것 이상의 영향을 미치지는 않습니다.

그러나 위의 두 가지 체계는 연속 배포를 사용하는 환경 (예 : 스택 교환)에만 적용되지 않습니다. 스택 교환에서 사용되는 것으로 보이는 일종의 날짜와 개정 번호가 선호됩니다. 사이트. 지속적인 배포 환경에서 버전이 너무 자주 변경되고 동일한 날짜에 여러 버전의 코드가 올라와 개정 번호를 정당화 할 수 있고 현재 날짜가 문제를 해결하는 데 도움이되는 이유가 있습니다. 훨씬 더. 이론적으로는 모든 것에 개정 번호를 사용할 수 있지만 현재 날짜를 사용하면 내부적으로 주요 이정표를 추적하여 상황을 쉽게 논의 할 수 있습니다.

날짜를 사용할 때의 문제는 사양이 마감일이 아닌 계산 번호에 대해 기록된다는 것입니다.

"이 기능은 릴리스 1에있을 예정입니다. 다른 기능은 릴리스 2에 있습니다."

출시 날짜가 누락 될 수 있으므로 사양에서 날짜를 참조 할 수 없습니다.

사전에 다른 릴리스가 필요한 공식적인 프로세스가 없다면 날짜를 사용하는 것이 좋습니다. 믹스에 다른 번호를 추가 할 필요가 없습니다.

버전 번호 는 컨텍스트가 사양에 연결되어 있기 때문에 날짜를 포함하지 않을 수 있습니다.
빌드 번호 는 날짜가 포함되어있을 가능성이 높습니다. 컨텍스트는 빌드시기와 연결되어 있기 때문입니다.

이 방법은 설명한대로 이점이 있지만 날짜를 버전 번호로 사용하면 몇 가지 단점이 있습니다.

• 날짜 기반 버전은 단순합니다. v2.1.3에서는 버전 번호, 하위 버전 번호 및 하위 하위 버전 번호를 볼 수 있습니다. 20110119에서는 기록 된 시점 만 볼 수 있습니다. 당신은 할 수 그룹 월별로 날짜 기반 버전,하지만 여전히 아무 말도하지 않을 것입니다. 몇 달 동안 느리게 작은 버그 수정을 한 다음 2 주간의 무거운 코딩으로 인해 주요 릴리스가 될 수 있습니다. 날짜는 일반 버전 번호가 아니라고 알려줍니다.

• 실제로 매일 버전과 릴리스 번호를 변경해야하는 경우 적절한 릴리스 프로세스가 없음을 나타낼 수 있지만 대신 모든 사람이 원하는대로 변경하여 프로덕션 서버로 승격시킵니다. 그렇다면 프로세스에 문제가 있으며 다른 버전 번호 스키마를 사용해도 문제가 해결되지 않습니다.

버전은 종종 특정 버전의 소프트웨어가 이전 버전과 어떻게 다른지에 대한 정보를 전달하는 데 사용됩니다. 예를 들어 Acme 1.0에서 2.0으로 업그레이드하는 경우 이론상 주요 변경 사항이 적용되는 주요 업그레이드입니다.

반면 1.0에서 1.1 로의 업그레이드는 약간의 업그레이드이며 이론 상으로는 약간의 점진적인 변경과 버그 수정이 수반됩니다.

혼합을 사용할 수는 있지만 날짜 형식으로 표현하기는 어렵습니다. 예를 들어, v1.0.YYYY.MMDD

다른 답변에서 좋은 아이디어를 반복하지 않고 아직 해결되지 않은 문제가 있습니다.

이전 버전과의 호환성을 위해 이전 버전과 호환되지 않는 현대화를위한 새 버전 사이에서 포크를 수행하는 경우 버전 번호를 통해 구별 할 수 없습니다.

예를 들어, Linux 커널은 2000 년 경에 기존 2.4.x 브랜치로 분기되었으며 현재 2.4.199로 계산되며 새 버전은 수년 동안 2.6이었으며 2.6.32입니다. 이전 시스템의 경우 최신 커널의 경우 3.2입니다.

릴리스에 대한 문서가있는 경우 정보를 두 배로 늘리고 20120109 버전이 2012 년 1 월 9 일에 도착했다고 사람들에게 알립니다. ㅁ 그러나 마지막 순간 버그 감지가 있고 릴리스가 일주일 동안 지연되지만 이름이 언급 된 문서가 이미 준비되어 있거나 인쇄되어 있거나 정보가 인쇄되지 않은 경우 어떻게해야합니까? 이제 20120109 버전이 2012/01/13에 도착하면 문제가되는 불일치가 있습니다.

SQL에서 ID가 의미 정보를 전달해야하는지에 대한 질문이 종종 논의되었으며 그 결과는 항상 다음과 같습니다. 지옥처럼 피하십시오! 불필요한 의존성을 만들고 있습니다. 도움이되지 않습니다.

04/10 방식의 Ubuntu는 버전 6.04가 지연되어 6.06이 된 2006 년에 문제가있었습니다. 3000 년에 곧 다음 문제가있을 것입니다! :)

날짜를 버전으로 사용하는 많은 소프트웨어 패키지가 있습니다. 우분투 버전은 YY.MM입니다. 그리고 Microsoft Office 제품 의 빌드 번호 도 빌드 날짜의 인코딩입니다. Jeff Atwood는 다음 권장 사항을 포함하여 버전 번호 지정에 대한 코딩 공포 블로그 게시물을 작성했습니다 .

가능하면 버전 번호 대신 간단한 제품 날짜를 사용하십시오 (공개 제품 이름). 그리고 절대적으로 내부적으로 버전 번호를 사용해야하는 경우 어쨌든 날짜를 확인하십시오. 버전 번호의 어딘가에 빌드 날짜를 인코딩하십시오.

내 의견으로는, 당신이 구성적이고 빌드 버전 번호 (무엇이든)에서 나가고 버전 제어 시스템에서 해당 빌드에 들어간 모든 아티팩트를 리콜 할 수있는 한 중요하지 않습니다. 사용자는 일반적으로 버전 정보에 신경 쓰지 않고 시스템에서 제공하는 기능에 관심을 갖습니다. 버전 정보는 개발자에게 진정한 가치입니다.

시맨틱 버전 관리를 사용하면 코드 자체를 검사하지 않고도 버전간에 변경되는 내용을 알 수 있습니다. http://semver.org/

버전 번호를 사용하면 변경이 얼마나 큰지 보여줄 수 있습니다

예를 들어 2.4.3은 버전 2가 전체 시스템의 주요 변경 사항임을 의미 할 수 있습니다. .4는 사소한 업데이트입니다. 마지막 .3은 해당 버전에 대한 작은 버그 수정입니다. 그렇게하면 각 버전간에 얼마나 많은 변화가 있었는지 쉽게 알 수 있습니다.

릴리스 노트와 해당 릴리스의 범위에 대한 문서를 추적하는 방법을 찾을 수있는 한 많은 사람들이 날짜 또는 SCM 개정 번호를 버전 번호로 사용한다고 여전히 말했지만 실제 문제는 없습니다.

여기에 좋은 대답이 있지만 날짜를 사용하는 것이 완벽하게 이해되는 경우를 지적하고 싶습니다. 코드가 자주 업데이트 될 가능성이 있지만 작은 버전으로 이전 버전과 크게 다른 작은 라이브러리 또는 작은 코드 조각 하나.

즉, 실제 "버전 번호"는 없지만 기본적으로 일종의 준 일일 저장소 덤프가있는 상황에 대해 이야기하고 있습니다.

이런 종류의 것들을 접할 때 일반적으로 선택을 환영합니다. 특정 버전이 아닌 비교적 최신 스크립트 / lib를 사용하고 있음을 알면 더 유용합니다.

버전 번호 날짜는 마케팅에 좋습니다. 사람들이 "Windows NT 5.0"을 사용하고 있다면 사용되지 않을 수도 있습니다. 그러나 사람들이 여전히 "Windows 2000"을 사용하고 있다면 12 살짜리 OS라는 것을 즉시 알 수 있으며 업그레이드를 권장합니다.

그러나 "주"및 "부"업데이트를 구분하기가 어렵습니다.

날짜를 버전 번호로 사용하는 문제

여기에 대한 답변은 좋지만 날짜를 사용 하여이 문제를 해결하는 사람은 없었습니다. 사용자는 수정 빈도를 결정할 수 없습니다.

내가 말하려는 것은 Windows 3.1과 Windows 7이 멀리 떨어져 있고 아마도 호환되지 않는다고 말할 수 있다는 것입니다. Windows 95와 Windows 2000은 제품이 출시 된 연도에 그치지 않습니다.

예를 들어 Python을 사용하면 버전 2.7.2가 2.4.6에서 진화 한 것을 알고 있습니다. 더 자세히 살펴보면 2008 년 12 월 19 일에 버전 2.4.6이 릴리스 된 것입니다. 이 버전 2.7.2는 2011 년 6 월 11 일에 릴리스되었습니다. 이로부터 제품의 안정성 (예 : 릴리스 빈도)에 대한 의견을 제시 할 수 있습니다.

대신 파이썬이 출시 날짜를 사용한 경우 이러한 제품이 어떻게 연결될 수 있는지 알 수 없습니다. 파이썬 3.1.4가 2011 년 6 월 11 일에 출시되었으므로 (파이썬 2.7.2와 동일) 추가 혼란이 발생합니다.

간단히 말해서, 나는 그 자체로 날짜 버전 관리가 가치 있다고 생각하지 않습니다.

나는 이미 다른 사람들이 묘사 한 이유로이 아이디어를 좋아하지 않습니다. major.minor.bugfix 구성표 만 사용하십시오. 대부분의 사람들이 이런 식으로하는 이유가 있습니다.

그러나 당신이 무엇을하든 : 하나의 버전 명명 체계를 선택하고 그것을 고수하십시오 . 모든 릴리스마다 구성표를 변경하는 Windows와 같이하지 마십시오. 또한 Android와 같이하지 마십시오. 각 릴리스에는 API 버전 번호 (8), 마케팅 용 버전 번호 (2.2) 및 멍청한 이름 (Froyo)이 있습니다.

버전으로 날짜

제품을 판매하지 않은 경우 날짜를 사용하는 것이 좋으며 유용 할 것입니다. 판매하고 고객에게 업그레이드하면 특정 기능 세트가있는 모델을 구매하려고합니다. 이 모델의 이름이 분명하면 업그레이드로 판매하는 것이 훨씬 쉽습니다. 예를 들어 실제로는 중요하지 않지만 2012 년 1 월 20 일 포드 자동차를 구입 한 사람은 아무도 기아 모델을 원하지 않습니다. 소프트웨어도 마찬가지입니다. 하드 모델 이름과 버전을 제공하면 이전 모델과 다른 기능이 있습니다. 나에게 데이트는 그렇게하지 않는다. 내가 그것을 만들었다 고 말하지만 새로운 기능을 가지고 있지는 않다.

우리가 사용하는 계획

나는 우리 시스템이 위와 같이 명확한 브랜드를 만든다고 주장하지 않았습니다. 우리는 이제 네 부분 구성표를 사용합니다. 버전 번호, 상태, 날짜 및 체크섬

1200_GLD_120120_F0D1

이것은 최고 수준으로 이길 수 있지만 엔지니어가 사용할 수있는 버전 1200 용 빌드의 여러 버전을 가질 수 있으며 날짜별로 구별 할 수 있습니다. 상태는 그것이 내부 테스트 버전, 고객 패치 빌드 또는 골드 버전을 경우 사람을 말한다. 검사는 그들이 실제로 우리의 유통에서 올바른 하나를 다운로드했는지 확인하기 위해 엔지니어 또는 고객 수, 새로운 기능입니다.

그래서 우리는 일련의

1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD

우리는 일반적으로 고객 (예 : "12")의 주요 버전 번호만을 참조하지만 고객은 수정이 필요하지 않은 한 최신 골드 버전 인 12 (예 : 1200_GLD_120120_F0D1)를받습니다.

일부 고객이 제품의 버전 2를 사용하고 일부 고객이 버전 3으로 업그레이드했으며 그 업그레이드가 간단한 결정이 아니라고 가정 해 봅시다.

버전 2의 마지막 버전이 2.3.2이고 버전 3이 3.0.3이라고 가정하십시오. 이제는 반드시 수정해야하는 취약점을 발견하여 같은 날 2.3.3 및 3.0.4를 릴리스합니다. 출시 날짜가 전혀 관련이없는 것을 볼 수 있습니까? 2013 년에 버전 2에 대한 작업을 중단하고 그 이후로 몇 가지 필수 버그 수정 만 릴리스했을 수 있습니다. 날짜는 버전 번호와 관련이 없습니다.

나는 그것이 잘 작동한다고 생각합니다. 내부 소프트웨어 (yyyy.mm.dd)와 공개 한 일부 오픈 소스 소프트웨어에 사용합니다.

모든 경우에 작동하지 않을 수 있습니다.

기술적으로 버전 번호에는 날짜를 사용할 수 없지만 고객의 날짜 번호를 표시 할 수 있습니다. 예를 들어, macOS 16.7.23 --- 다음을 의미합니다 : 23/7/2016

나는 기술이 문제가 아니라고 생각한다. 문제는 그것이 어떻게 느끼는가? 소프트웨어를 생생하게 만들 수있는 날짜 번호를 생일 번호를 가진 사람처럼 살면 매년 우리가 자라면서 소프트웨어와 같은 것은 계속 자랍니다.

건물 번호는 기계, 기계, 살아있는 것, 살아있는 것 같은 것 같습니다.