자식 태그에 대한 표준 명명 규칙이 있습니까?

자식 태그에 대한 표준 명명 규칙이 있습니까? [닫은]

---

v1.2.3git에서 태그의 명명 규칙으로 사용하는 많은 프로젝트를 보았습니다 . 또한 일부 사용을 보았습니다 1.2.3. 공식적으로 승인 된 스타일이 있습니까, 아니면 둘 중 하나를 사용하기위한 좋은 주장이 있습니까?

---

GitHub 명성의 Tom Preston-Werner 의 Semantic Versioning 버전 1.0.0 에는 다음과 같은 하위 사양 이 있습니다.

태깅 사양 (SemVerTag)

버전 관리 시스템 (Git, Mercurial, SVN 등)을 사용하여 코드를 저장하는 경우이 하위 사양을 사용해야합니다. 이 시스템을 사용하면 자동화 된 도구로 패키지를 검사하고 SemVer 준수 및 출시 된 버전을 확인할 수 있습니다.

1. 버전 제어 시스템에서 릴리스에 태그를 지정할 때 버전의 태그는 "vX.YZ"여야합니다 (예 : "v3.1.0") .

그러나 토론 후에 이것은 제거되었으며 더 이상 최신 버전의 SemVer 사양 (작성 당시 2.0.0)에 존재하지 않습니다 . 같은 장소에있는 나중의 토론 스레드는 더 깊이 들어가서 "v1.2.3"이 의미 버전입니까? 되는 추가 SemVer의의 질문에 master글을 쓰는 시점에서 (이상 나중에 2 년)이 변화가 있지만, 지점 아직 존재하지 공식적으로 출시 된 사양이다.

---

릴리스 자체에 번호를 매기는 데 합리적인 표준을 준수한다고 가정하면 두 가지 지배적 인 규칙이있는 것 같습니다.

• v1.2.3
• 1.2.3

장점은 v1.2.3Git 문서 (및 Mercurial 문서)가 예제에서 해당 형식을 사용하고 Linux 커널 및 Git 자체 와 같은 여러 "권한" 이이 를 사용한다는 것입니다. 언급 된 시맨틱 버전 관리 는이를 사용했지만 더 이상 사용하지 않습니다.

의 장점은 1.2.3그 gitweb 또는 GitHub의 자동 타르볼을 제공하거나 양식의 다운로드를 압축 할 수 있습니다 packagename-$tag.tar.gz(그리고 나는 꽤 타르볼이해야 확립 생각 하지 라는 이름 package-v1.2.3.tar.gz). 또는 git describetarball 버전 번호를 생성 하는 데 직접 사용할 수 있습니다 . 공식적인 릴리스 프로세스가없는 경량 프로젝트의 경우 이러한 가능성이 매우 편리 할 수 ​​있습니다. 또한 시맨틱 버전 관리는 버전 번호 매기기에 대해 유일하게 또는 보편적으로 인정되는 표준은 아닙니다. 수많은 다른 프로젝트뿐만 아니라 그놈과 같은 주목할만한 프로젝트는 1.2.3태그 이름을 사용합니다 .

이 입장을 정리하기에는 너무 늦었다 고 생각합니다. 항상 그렇듯이 일관되고 이해하십시오.

---

업데이트 : 이 의견 에서 언급했듯이 GitHub는 이제 태그에서 'v'가 제거 된 tarball 이름을 제공합니다.

---

앞의 'v'에 대한 이유는 역사적입니다. 이전 SCCS (cvs, rcs)는 태그 식별자와 개정 번호를 구별 할 수 없습니다. 개정 번호를 감지 할 수 있도록 태그 ID는 숫자 값으로 시작하지 않도록 제한되었습니다.

---

내가 아는 한에서는 아니다.
그러나 Git은 같은 이름의 태그와 분기를 동시에 허용 하지 않으므로, 작업에 " 1.1" 분기가있는 경우 " " 1.1태그를 넣지 마십시오. 1.1예를 들어 " v1.1"

---

새로운 패키지 관리자 는 PHP 프로젝트의 작곡가 와 같이 접두사가 없는 버전에 태그를 지정하도록 조언합니다 . SemVer 2.0 에는 태그 지정에 관한 내용이 없습니다. 의도적으로 충돌을 피하기 위해 수행됩니다. 그러나 설명서 및 텍스트 참조에 접두사를 추가하는 것이 좋습니다 . 예를 들어 형식으로 대신 전체 또는 인만큼 자세한 정보 및 문서의 우아한.vvv1.0.4version 1.0.4ver. 1.0.4

---

릴리스 별 작업에 대해 브랜치와 태그를 각각 사용하고 실제 릴리스는 다음과 같습니다.

o---o-----o---o---o--- ...   master
     \   /       /
      \ /       /
       o-------o--- ...      1.6 branch

모든 개발자는 커밋하려는 작업이 마스터에 적용 가능한지 또는 브랜치와 관련이 있는지 여부를 신중하게 결정합니다. 브랜치에 대한 변경 사항은 마스터에서 다시 병합되지만 마스터의 일부 변경 사항은 브랜치에 적용되지 않습니다 (즉,이 예에서는 1.6 릴리스 용이 아닌 변경 사항).

릴리스 할 준비가되면 태그를 지정하고 마지막으로 다시 병합 한 다음 분기와 동일한 이름을 사용하지만 특정 버전에 대한 추가 식별자 (예 : "1.6-release")를 사용하여 태그 이름을 지정합니다. 또는 "1.6- 베타"또는 "1.6-rc2"등.

... ------o---o---o--o---o--- ...   master
         /       /
        /       /
... ---o------(*)--- ...      1.6 branch
          1.6-release

---

나는 어떤 표준도 모른다. 나는 단순히 태그 이름을 선택하여

VERSION = `git describe --tags`

내 빌드 스크립트에서. 따라서 태그 이름 지정 규칙은 실제로 프로젝트의 버전 이름 지정 규칙에 따라 다릅니다.

---

There is no one best practice I'm aware of. Here are some links:

• http://web.elctech.com/?p=79
• http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html#production-tagging

Generally, versioning (0.0.1, v0.2.1, ...) maybe hand in hand with some issue-tracking could be considered a plausible approach. (.. although I usually use v-prefixed tag names .. see also @VonC answer)

참고URL : https://stackoverflow.com/questions/2006265/is-there-a-standard-naming-convention-for-git-tags