초기 버전으로 무엇을 사용해야합니까? [닫은]

저는 보통 1.0.0 버전으로 프로젝트를 시작합니다. 함께 몇 가지를 준비하자마자 1.0.0으로 릴리스하고 1.1.0으로 넘어갑니다.

그러나 이것은 사용 가능하지만 내가 작성하는 대부분의 항목의 완전한 버전 1.0.0을 정확하게 기능하지는 않습니다. 그런 다음 기능을 추가하고 1.6.0 정도의 괜찮은 버전을 얻습니다. 많은 프로젝트가 버전 0.1.0으로 시작하여 1.0.0만큼 사용할 수 있습니다.

무엇을 제안 하시겠습니까? 1.0.0 또는 0.1.0으로 시작 하시겠습니까?

마지막 번호는 버그 수정 릴리스 용입니다. 내 1.0.0을 1.0으로, 0.1.0을 0.1로 생각하면 더 쉽습니다.

내 버전 관리는 설정에 따라 결정됩니다. 나는 그것이 이전 버전을 대체하기를 원하므로 나에게 의미있는 점프로 계속 증가시킵니다.

그러나 때때로 버전 관리는 고객이 주도하며, 특히 코드를 대중에게 공개하는 경우 더욱 그렇습니다.

그것이 당신의 부름이라면 당신에게 가장 적합한 것을하십시오. 1.0 이전 버전에서 몇 가지 문제가 있었으므로 시작합니다.

시맨틱 버전 2.0.0 표준은 말합니다 :

가장 간단한 방법은 초기 개발 릴리스를 0.1.0에서 시작한 다음 각 후속 릴리스에 대해 부 버전을 증가시키는 것입니다.

0.3.0에서 1.0.0으로가는 것은 괜찮습니다. 0.23.0이 되어도 괜찮습니다. 0.4.0에서 시작하는 것은 이전에 게시 된 버전이 있음을 나타내므로 권장하지 않습니다.

또한 0.y.z빠른 반복을 위해 따로 보관하므로 초기 개발 (따라서 많은 주요 변경 사항)으로 인해 142.6.0과 같은 어리석은 일이 발생하지 않습니다. 주 버전을 범프하는 대신 1.0.0을 릴리스 할 때까지 모든 주요 변경 사항에 부 버전을 범프하십시오.

주 버전 0 (0.yz)은 초기 개발 용입니다. 모든 것은 언제든지 변경 될 수 있습니다. 공개 API는 안정적인 것으로 간주되어서는 안됩니다.

버전 번호는 전적으로 귀하에게 달려 있습니다. 당신에게 의미있는 일 을 하고 일관성을 유지하십시오. 아무도 0, 0.0, 1.0, 1.1에서 시작해야한다고 말하지 않습니다.

훌륭한 프로그래머는 실제로 버전 번호 시스템을 지역 농담으로 사용했습니다. 예 (Wikipedia) :

버전 3부터 TeX는 버전 번호가 점근 적으로 π에 가까워 지도록 십진수 끝에 추가 숫자를 추가하여 업데이트가 표시되는 특이한 버전 번호 지정 시스템을 사용했습니다. 이것은 TeX가 이제 매우 안정적이며 사소한 업데이트 만 예상된다는 사실을 반영합니다. 현재 TeX 버전은 3.1415926입니다. 2008 년 3 월에 마지막으로 업데이트되었습니다.

METAFONT의 경우 :

Metafont는 TeX와 유사한 버전 관리 시스템을 가지고 있으며, 각 개정마다 숫자가 점근 적으로 e에 접근합니다.

마지막으로 버전 번호는 아니지만 똑같이 흥미로운 점은 Google의 IPO (공개 공모)가 2,718,281,828 달러를 모금하기 위해 SEC에 제출되었다는 것입니다 (e ~ 2.718 281 828).

내 요점은 : 군중을 따라갈 필요가 있다고 생각하지 마십시오. 창의적이고 일관 적입니다.

여기에서 다른 요인이 작용한다고 생각합니다. 버전 번호의 심리적 / 마케팅 적 영향 (버전 번호가 자주 증가 => 더 많은 $$$, 사람들이 0.99 베타 버전을 구매하고 싶지 않음 등)을 고려해야합니다. "논리"버전 번호는 대규모 팀에서 작업 할 때 도움이 될 수 있습니다.

그리고 불안정한 버전에는 홀수를, 안정적인 버전에는 짝수를 사용하는 리눅스 방식을 좋아합니다.

첫 번째 사용 가능 버전을 준비했지만 기능 완성 버전이 아닌 경우 일반적으로 기능 완료 버전이 얼마나 진행되는지 판단하려고합니다. 예를 들어 첫 번째 사용 가능한 기능이 33 % 기능 완료이면 버전 번호를 0.3.0 또는 비슷한. 그런 다음 기능 완성으로 이동하면 해당 버전이 비슷한 방식으로 주어진 번호를 얻습니다.

그러나 과거 기능으로 이동하면 완전한 버전 관리가 변경되어야합니다.

npm패키지의 버전 번호를 선택할 때 package.json semver 범위에 나열된 종속성의 경우 v1.0.0 미만에서는 작동하지 않습니다. 그건,

"dependencies": {
    "my-package": "^0.5"
}

다음과 같다

"dependencies": {
    "my-package": "0.5"
}

semver 범위를 사용하거나 다른 사람이 사용하도록하려면 1.0.0부터 시작하는 것이 좋습니다.

일반적으로 버전 관리는 프로그래머에게 어떤 의미가 있습니다. 주 번호를 늘리면 이전 버전과의 호환성을 방해하는 큰 변경 사항을 나타낼 수 있습니다. 버전 번호의 다른 숫자는 더 작은 기능 향상 또는 버그 수정을 나타낼 수 있습니다.

버전 0.6.5에 불완전한 링이 있는지 걱정된다면 버전 1.0으로 마케팅하는 것이 좋습니다. 마케팅 버전 번호는 내부 버전 번호와 일치하지 않아도됩니다. 예를 들어 Windows 7의 버전 번호는 6.1입니다.

개인적으로 선호하는 것은 0.1.0에서 시작하여 거기에서 시작하는 것입니다.

프로젝트에 따라 다릅니다. 간단한 명령 줄 도구의 경우 거의 완료 될 때 (또는 베타 테스트 준비가되었을 때만 릴리스하거나 포장하는 것을 고려하기 때문에) 보통 0.9 [.0]에서 시작합니다. 더 복잡한 프로젝트는 0.1 [.0]에서 시작합니다. 일부는 1.0도 보지 못합니다. 1.0을 릴리스 버전 (또는 적어도 로컬에서 테스트 한 베타 또는 릴리스 후보)으로 간주하고 그에 따라 계획합니다.

팀 프로젝트를 사용하면 첫 번째 버전 태그를 넣는 사람이 결정하게됩니다. :).

0.1.0은 내가 시작하고 거기에서 위로 이동하는 것입니다. 이것이 제가 Xploration By Adrian에 적용한 것입니다. 초창기에는 매우 산발적이었고 1.0.0, 0.0.1 및 기타 몇 가지를 사용했습니다. 그러나 0.1.0에서 시작하여 거기에서 시작하는 것이 좋습니다.

Semver에 따라 A를 위해 abc로 a 및 c를 예약합니다. 첫 번째 공식 릴리스와 C. 버그 수정 및 패치입니다. 이는 주 버전이 일반적으로 이전 코드를 손상시키기 때문입니다. 패치는 단순히 버그를 수정합니다. 이것은 모두 개인적인 선호입니다. 0.99.0은 1.0.0으로 가야한다는 것을 의미하지 않습니다. 저는 0.218.42까지가는 것을 보았습니다.

Arrieta가 이전에 올바르게 설명 했듯이 버전 번호는 의미가 있어야합니다 .

다음과 같을 수 있습니다. 첫 번째 #은 시장 릴리스이고, 두 번째 #은 일부 기능이 추가 된 동일한 시장 릴리스이고, 세 번째 #은 동일한 기능이 있지만 버그가 수정되었거나 약간의 (하지만 충분히 중요한) 변경 사항이 추가 된 동일한 시장 릴리스입니다.

1.3.2 => 첫 번째 릴리스, 더 많은 기능과 일부 버그 수정.

그러나 최종 사용자의 경우 일부는 최종 릴리스를 위해 큰 숫자에 익숙합니다.

예 : Corel 8, 8.0.0, 8.0.1, 8.2.2 등. Corel 9, 9.0.0 ... 등.

그리고 대부분은 Corel 15.0.2 대신 Corel X5와 같은 마케팅 전략에 관한 것입니다.

버전 번호가 사용자 용인지 클라이언트 용인지에 따라 다릅니다.

0.0.0으로 시작하여 거기에서 이동합니다.

1.1.1로 시작하여 거기에서 이동하십시오.