시맨틱 버전 관리는 API가없는 프로그램에 어떻게 적용됩니까?

에서 http://semver.org/ 이 변화 나누기 / API가 도입 수정하는 것이 경우 주 버전 수를 증가하는 것이 좋습니다 versioning-에 - 어떤 내 인식에서 가장 널리 사용되는 규칙이 될 것으로 보인다.

이 지침을 적용하는 방법을 보지 못하는 두 가지 관련 시나리오가 있습니다.

1. 내 코드가 API를 제공하지 않으면 어떻게됩니까? 코드를 어떻게 버전 화해야합니까?
2. 내 코드가 개발 후반에 API를 제공하기 시작하면 어떻게됩니까?

Semver는 다양한 화신에서 의존성 지옥을 피하는 방식으로 라이브러리 및 패키지의 버전을 관리하는 데 주로 관심이 있습니다. 그러나 Semver 의 아이디어는 모든 종류의 프로그램으로 확장 될 수 있습니다. 모든 코드에는 사용자 인터페이스가 있거나 전혀 쓸모가 없습니다.

• 프로그래밍 라이브러리 또는 웹 서비스에는 API가 있습니다.
• 소비자 소프트웨어에는 GUI가있을 수 있습니다.
• 명령 행 프로그램에는 스위치 및 옵션 세트가 있습니다.
• 구성 파일도 사용자 인터페이스입니다.

워드 프로세서와 같은 소비자 소프트웨어의 예를 사용하여 :

• "당신이 버그 수정, 예를 들어 제공 할 때 패치 번호를 증가 응용 프로그램이 항상 화요일 00:00 PM에 충돌 고정 버그 ".
• 새 기능을 추가 할 때 부 버전 번호를 늘리십시오 (예 :“ 밑줄이있는 텍스트에 대한 지원 추가 ”).
• 사용자 인터페이스를 크게 점검하거나 모든 내부를 다시 작성할 때 주 버전을 늘리십시오. 예 : " 툴바는 너무 많은 화면 영역을 사용합니다. UI는 이제 터치 제스처를 통해서만 제공됩니다 ”– 이러한 변경으로 인해 기존 워크 플로가 중단 될 수 있습니다.

그러나 Semver가 해결하려는 많은 문제는 종속성 관리 영역 외부에 존재하지 않습니다. 소비자 응용 프로그램에서 버전은 버전 일뿐만 아니라 마케팅 자산이기도합니다.

• Firefox 및 Chrome은 새 버전을 비교적 자주 출시하며 각 릴리스마다 주요 버전 번호를 증가시킵니다. 이것은 엄청나게 높은 버전 번호를 초래합니다 (모두 현재 30 대입니다). 버전 번호가 높은 브라우저는 버전 번호가 낮은 브라우저보다 좋을 것입니다.

• Apple 운영 체제 OS X 의 주 버전 번호 는 이름의 일부가되었으며 (X는 로마 숫자로 10), 부 버전 번호는 유효 주 버전 번호입니다.

• Ubuntu 운영 체제는 year.month.patchlevel 버전 관리 체계를 사용합니다. 이를 통해 OS의 수명을 기억할 수는 있지만 호환되는 버전과 각 버전에 대한 지원 기간을 파악하기가 훨씬 어렵습니다.

• 리눅스 커널 39은 리눅스의 20 주년을 기념하기 위해 2.6.39에서 3.0.0으로 버전 번호를 올렸습니다 .

• Donald Knuth의 전설적인 TeX 조판 시스템은 버전 3을 기준으로 각 릴리스에서 다른 숫자를 추가하여 π로 수렴되는 버전 번호를 사용합니다. 3.14159265…. 이것은 시스템이 완벽에 가까워지고 있음을 나타냅니다. 마찬가지로 Metafont 시스템은 e : 2.7182818…로 수렴됩니다 .

따라서 많은 응용 프로그램이 Semver에서 제대로 제공되지 않습니다. 동료 프로그래머인지 소비자인지에 관계없이 사용자에게 적합한 버전 관리 체계를 선택하고 일관성을 유지하십시오.