Auto: 핫픽스 - 이전 미성년자 및 패치에 대한 패치 지원

@hipstersmoothie
이것이 어떻게 구현되는지 / 실제로 어떻게 보일지에 대한 세부 정보가 있습니까?

또한 merge into a tag 의미하는지 잘 모르겠습니다... 잠재적으로 명확히 해주실 수 있습니까? 내 이해는 지점을 대상으로 하는 PR만 만들 수 있다는 것입니다.

아니요, 나는 문제에 대해 너무 많이 생각하지 않았습니다.

또한 태그에 병합이 의미하는 바를 이해하고 있는지 잘 모르겠습니다.

UI를 통해 태그로 병합할 수 있다고 믿게 되었지만 추가 검토를 통해 이것은 불가능한 것 같습니다. 우리가 할 수 있다면 이것이 가능하게 될 것입니다.

조금 생각해보면 이런 생각이 들더군요.

1. 태그 1.2.3이 존재하며 현재 버전은 2.0입니다.
2. PR은 태그 1.2.3으로 만들어지고 1.2.3-0을 생성합니다(0은 semver의 빌드 부분임).

좋아, semver의 빌드 부분을 활용하는 것은 확실히 의미가 있습니다. 👍

태그에 직접 PR을 생성할 수 없는 경우 이 흐름은 저장소 소유자가 업스트림 브랜치(PR 대상 브랜치)의 태그에서 브랜치를 생성하도록 요구할 수 있습니다. 약간 성가시겠지만 더 나은 대안이 있을지 모르겠습니다. 또한 이러한 유형의 릴리스는 일반적이지 않으므로 괜찮을 수 있습니다.

이전 주요 지원( versionBranches )에 대한 유사한 접근 방식을 구성에서 분기 접두사를 지정할 수 있는 경우 사용할 수 있습니다. 이 기능은 핫픽스 유형 릴리스를 대상으로 할 수 있으므로 구성을 이전 주요 지원과 별도로 유지하는 것이 좋습니다. 어떻게 생각하나요?

예시 흐름은 다음과 같습니다.

• 사용자는 자동 구성에서 hotfix- 접두사가 있는 분기에 대한 빌드 식별자를 사용하여 빌드하도록 지정합니다.
• 기존 커밋 로그
  <ul> <li>(tag: v2.0.0) (master)<br /> |</li> <li>(tag: v1.2.0)<br /> |</li> <li>(tag: v1.1.0)<br /> |</li> <li>(tag: v1.0.0)<br />

구성에서 분기 접두사를 지정할 수 있는 경우 이전 주요 지원(versionBranches)에 대한 유사한 접근 방식을 사용할 수 있습니다.

아이디어는 마음에 들지만 실제로 사용하는 것이 그렇게 재미있지는 않을 것 같습니다. auto 는 많은 것을 릴리스하기 때문에 미친 수의 분기로 끝날 것입니다.

태그에 직접 PR을 생성할 수 없는 경우 이 흐름은 저장소 소유자가 업스트림 브랜치(PR 대상 브랜치)의 태그에서 브랜치를 생성하도록 요구할 수 있습니다. 약간 성가시겠지만 더 나은 대안이 있을지 모르겠습니다. 또한 이러한 유형의 릴리스는 일반적이지 않으므로 괜찮을 수 있습니다.

나는 이러한 유형의 릴리스가 정상적이지 않다는 데 동의합니다. 이는 자동화된 분기 생성을 덜 유용하게 만듭니다. 그렇게 많이 사용하지 않고도 많은 노이즈(더 많은 분기)를 얻을 수 있습니다.

위에서 제안한 흐름은 잘 작동하는 것 같습니다. 하지만 PR을 태그로 만들 수 없다는 것은 유감입니다! 이 워크플로를 더 쉽게 만들 수 있습니다.

이에 대해 생각해보면 이 기능이 완전히 구체화되려면 auto 에 몇 가지 사항이 필요할 것입니다.

1. 새 명령 auto hotfix : 실행 시 분기의 최신 태그를 기반으로 하는 새 핫픽스 버전으로 프로젝트를 릴리스합니다.
2. auto shipit 새로운 기능: hotfixBranch 에 있는지 감지하고 auto hotfix

auto hotfix 이 작동하는 방식에 관해서는 다음 중 하나를 사용할 수 있습니다.

1. next or canary => 핫픽스가 지원되는지 여부를 플러그인에서 제어할 수 있는 새로운 후크
2. version 및 publish 후크를 재사용하고 build semver를 해제할 수 있도록 합니다.

두 가지 옵션 중 version 및 pubish 후크를 새로운 방식으로 호출하는 것은 획기적인 변경으로 간주될 수 있기 때문에 1 쪽으로 기울고 있다고 생각합니다. 단점은 일부 후크가 afterVersion 로 호출되지 않아 일부 플러그인이 작동하지 않는다는 것입니다. 이것은 현재 canary 및 next 모두에 대한 문제입니다. 그들은 그 후크를 부르지 않기 때문에. 따라서 즉시 걱정할 필요가 없는 것입니다.

이것을 추가하는 데 관심이 있습니까?

아이디어는 마음에 들지만 실제로 사용하는 것이 그렇게 재미있지는 않을 것 같습니다. auto가 많이 릴리스되기 때문에 미친 수의 분기로 끝날 것입니다.

죄송합니다. 분기 접두사 구성이 있다는 점에서 이전 주요 지원과 유사하다는 것을 의미했습니다. 분기를 자동으로 생성하면 특히 자주 릴리스할 때 너무 많은 소음이 발생한다는 데 동의합니다. 😆

이것에 대해 생각해보면, 이 기능은 완전히 구체화되기 위해 auto에 몇 가지가 필요할 것입니다.

1. 새 명령 자동 핫픽스: 실행 시 분기의 최신 태그를 기반으로 하는 새 핫픽스 버전으로 프로젝트를 릴리스합니다.
2. auto shipit의 새로운 기능: hotfixBranch에 있는지 감지하고 자동 핫픽스를 실행합니다.

네. 나는 그것이 필요한 변경 사항을 크게 요약 할 것이라고 생각합니다.

자동 핫픽스가 작동하는 방식에 관해서는 다음 중 하나를 사용할 수 있습니다.

1. 다음 또는 카나리아의 방법 => 핫픽스가 지원되는지 여부를 플러그인이 릴리스하는 방법을 제어할 수 있는 새로운 후크
2. 버전을 재사용하고 후크를 게시하고 빌드 semver를 릴리스할 수 있도록 합니다.

두 가지 옵션 중 1에 기대고 있다고 생각합니다. 왜냐하면 새로운 방식으로 버전 및 게시 후크를 호출하는 것이 획기적인 변경으로 간주될 수 있기 때문입니다. 단점은 일부 후크가 afterVersion으로 호출되지 않아 일부 플러그인이 작동하지 않는다는 것입니다. 이것은 현재 canary와 next 모두에 문제입니다. 그들은 그 후크를 부르지 않기 때문에. 따라서 즉시 걱정할 필요가 없는 것입니다.

높은 수준, 나는 1도 의미가 있다고 생각합니다. 어떤 후크가 어떤 명령에 대해 호출되는지 더 잘 이해하려면 코드를 추적해야 하지만 next , canary , & hotfix 모두 유사한 패턴을 따르는 경우 그러면 나중에 문제를 해결하기가 더 쉬울 것입니다.

이것을 추가하는 데 관심이 있습니까?

물론입니다 👍, 기꺼이 하겠습니다.
아마 다음 주까지 이에 대한 구현을 살펴볼 수 없을 것입니다. 그러나 이 문제가 3월 이후 업데이트되지 않았기 때문에 괜찮을 것이라고 추측하고 있습니다.

엄청난! 이 작업에 대한 계획된 작업이 없으므로 모두 귀하입니다.

FWIW - version-MAJOR-MINOR 분기를 만드는 것과 같이 열등한 선택이라고 생각한 것과 정확히 일치하여 이것을 플러그인으로 구성하려고 했습니다. 우리의 현재 프로세스인 TBH에 대해 너무 많은 소음처럼 느껴지지 않습니다. 우리는 이미 각 릴리스 라인에 대한 분기를 생성합니다.

현재 versionBranches 의 주요 부분은 이 플러그인입니다 .

    this.hooks.beforeCommitChangelog.tapPromise(
      "Old Version Branches",
      async ({ bump }) => {
        if (bump === SEMVER.major && this.config?.versionBranches) {
          const branch = `${this.config.versionBranches}${major(
            await this.hooks.getPreviousVersion.promise()
          )}`;

          await execPromise("git", [
            "branch",
            await this.git?.getLatestTagInBranch(),
          ]);
          await execPromise("git", ["push", this.remote, branch]);
        }
      }
    );

SEMVER.minor 대한 지원을 추가하는 것은 간단해 보이지만 auto의 다른 부분에서 변경해야 할 부분이 무엇인지 모르겠습니다.

그것은 이전 릴리스에서 발생하는 일의 일부이지만 shipit 에서 이 확인도 통과해야 합니다.

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1442

그런 다음 여기로 이동하고 기본적으로 릴리스 계산을 시작할 위치를 재정의합니다.

https://github.com/intuit/auto/blob/f37945b45b7fef6ffdb00ffa0250de449e02b883/packages/core/src/auto.ts#L1509

메이저가 아닌 오래된 마이너/패치에 대해 고려해야 할 한 가지 고려 사항은 잠재적인 버전 불일치입니다. 미성년자의 경우 문제가 덜하지만

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *  (tag: v1.1.2) <- Need to add logic to find an available tag 
| /
*  (tag: v1.1.0) (hotfix-feature)
|
*  (tag: v1.0.0)

따라서 hotfix 명령이 필요하지 않을 수 있습니다. 대신 고유한 버전 번호를 시도할 수 있습니다. 그러나 이것에 대한 유효성 검사가 필요할 수 있습니다.

규칙 :

1. 이전 마이너/패치 릴리스 분기에서 메이저를 릴리스할 수 없습니다(필수).
2. 이전 패치 릴리스 분기에서 마이너를 릴리스할 수 없습니다(필요하지 않을 수도 있음).

@hipstersmoothie
다음 태그를 사용할 수 없는 이전 태그를 기반으로 하는 ci 설정이 있는 경우 기본 동작이 무엇인지 알고 있습니까?

내 추측으로는 이 오류가 어디에서 발생하는지 잘 모르겠지만(아마도 태그 푸시 시?) 실패가 있을 것입니다.

즉:

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.1.1)
|
|  *   <- what is current behavior if I try to release this commit
| /
*  (tag: v1.1.0) 
|
*  (tag: v1.0.0)

@hipstersmoothie가 지정한 규칙을 적용하는 것 외에도 try to unique version number 전략/구현에 대한 잠재적인 문제/혼돈이 하나 있습니다. @hipstersmoothie의 예에서 v1.1.2 는 v1.1.1 의 패치 릴리스로 다른 사람들이 볼 수 있지만 개발이 선형적이지 않았기 때문에 이것이 보장되지는 않습니다. v1.1.2 v1.1.1 의 변경 사항이 없을 가능성이 높기 때문에 v1.1.1 에서 v1.1.2 로 이전 버전과 호환되지 않는 변경 사항이 있을 수도 있습니다. 다음 고유 버전이 v1.1.0 에서 더 먼 거리에 있는 경우(즉, 다음 고유 버전이 v1.1.100 경우) 이는 악화되고 더 혼란스러울 수 있습니다.

semver의 빌드 메타데이터 부분을 활용하면 semver 사양에 따라 버전 우선 순위를 계산할 때 무시되기 때문에 이러한 혼란을 제한할 수 있습니다. 빌드 메타데이터 번호를 증가시키는 경우 증가하는 번호 대신 commit sha를 사용할 수 있습니다.

일반적으로 소프트웨어 개발이 반드시 선형적인 것은 아니므로 최상의 구현이 있는지 확신할 수 없습니다.

일반화하려면 분기에 관계없이 위의 전략을 지정하기 위해 일종의 구성 또는 후크를 가질 수 있습니다(또는 분기가 후크에 대한 매개변수일 수 있음).
이런 식으로 플러그인을 통해 다른 구현을 사용할 수 있습니다.

다음 태그를 사용할 수 없는 이전 태그를 기반으로 하는 ci 설정이 있는 경우 기본 동작이 무엇인지 알고 있습니까?

커밋 메시지에 [skip ci] 가 있기 때문에 일반적으로 태그가 빌드되지 않습니다.

다음 고유 버전이 v1.1.0에서 더 멀리 떨어져 있는 경우 이는 악화되고 더 혼란스러울 수 있습니다.

이것은 좋은 점입니다. 확실히 버전의 빌드 메타데이터 부분을 올바른 전략으로 만듭니다.

일반화하려면 분기에 관계없이 위의 전략을 지정하기 위해 일종의 구성 또는 후크를 가질 수 있습니다(또는 분기가 후크에 대한 매개변수일 수 있음).
이런 식으로 플러그인을 통해 다른 구현을 사용할 수 있습니다.

귀하의 게시물은 고유한 태그를 찾는 것이 혼란스러운 계획이며 우리는 아마 그렇게 해서는 안 된다고 확신했습니다.

어쩌면 우리가 믹스를 하면 효과가 있을지도 모릅니다. 패치와 오래된 마이너는 쉬워야 합니다. 전공에 대한 oldVersionBranches와 똑같은 방식으로 작동할 수 있습니다.

*  (tag: v2.0.0) (master)
| 
*  (tag: v1.2.0)
|
|  *  (tag: v1.1.5) <- Can merge patched into old minor branch, maybe error when PR has `minor`
| /
*  (tag: v1.1.4) <- branch: version-1.1
|
*  (tag: v1.0.0)

그런 다음 패치 패치를 위한 빌드 메타데이터 부분만 수행하면 됩니다.

from 및 useVerion 옵션이 병합된 상태에서 핫픽스를 수행하는 기본 제공 방법이 있습니까? 나는 오늘 하나를 만들어야했고 고통스럽게 수동으로하기로 결정했습니다.

컨텍스트를 위해 내 프로젝트는 7.7에 있습니다. 우리 프로젝트의 주요 소비자는 현재 7.5에 있는 버전을 출시하고 있으며 문제를 발견했으며 7.5.1이 필요하므로 출시 중간에 모든 것을 다시 QA할 필요가 없습니다. 최적은 아니지만 가끔 발생합니다.

수동 개입 없이는 내가 아는 한 이를 수행할 수 있는 방법이 없습니다. 여기 intuit 내부의 누군가가 결국 이것을 추가할 계획이라고 생각합니다. 나는 이것이 자동에서 매우 부족한 기능이라는 데 동의합니다.

굉장해! 감사합니다 🙏

우리(저와 @10hendersonm)는 이에 대한 솔루션을 개발했지만
관련된. 그러나 자동 및 플러그인만 사용합니다!

PR만 사용하여 프로젝트의 7.2.1, 8.1.1 및 8.2.2를 핫픽스했습니다.
(매우 신중하게).

사람들이 관심을 가질 경우 이를 공유하는 방법을 조사할 수 있습니까?

2021년 1월 14일 목요일 오후 7:27 Matt Felten [email protected]이 다음과 같이 작성했습니다.

굉장해! 감사합니다 🙏

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/intuit/auto/issues/1054#issuecomment-760583830 또는
구독 취소
https://github.com/notifications/unsubscribe-auth/AACI3Q6RKDONYJVH6UWUPFLSZ6KZNANCNFSM4LFJ4ULQ
.

나는 매우 관심이있을 것입니다!

모두들 안녕! 나는 이것을 기여하는 데 관심이 있습니다. 내 제안은 다음과 같습니다.

1. 일반적으로 auto 는 모든 version-* 분기를 존중하려고 시도합니다. 예를 들어 분기에서 version-1.1.4 로 패치를 병합하면 1.1.5 버전의 릴리스가 생성됩니다. 해당 버전이 이미 생성된 경우 NPM 릴리스 또는 Git 태그가 실패하지만 이는 정상적이고 예상되는 오류 사례입니다.
2. 우리는 업데이트 할 수 있습니다 versionBranches 받아 들일 "major" | "minor" | "patch" 가 지정한 내용에 따라 잠재적 핫픽스 지점을 생성 할 것이다. 이렇게 하면 version-* 분기를 수동으로 생성해야 하는 것과 수정이 필요하지 않을 때 유지해야 할 너무 많은 분기가 생기는 것 사이에서 절충안을 선택할 수 있습니다.

생각?

그러나 이는 정상적이며 예상되는 오류 사례입니다.\

나는 여전히 이것이 어떤 유형의 버전을 만들 것으로 기대합니다. 최근에 다른 것을 가져오지 않기 위해 특정 커밋에서 핫픽스를 릴리스하려는 경우가 있었습니다. 이 경우 위의 대화에서 semver의 빌드 부분을 사용할 수 있다고 생각합니다.

"major"를 허용하도록 versionBranches를 업데이트할 수 있습니다. | "사소한" | "반점"

현재 구성은 true 이거나 주요 분기에 접두사를 붙일 문자열일 수 있습니다. 새로운 구성은 다음과 같아야 한다고 생각합니다.

{
  "versionBranches": {
      "branchPrefix": "version-",
      "types": ["major", "minor"] // defaults to just major   
   }
}

대답할 마지막 질문은 여전히 핫픽스 후크 또는 호출 버전+게시 후크입니다. 우리는 옵션 2를 수행하고 버전+게시를 호출합니다(이는 실수로 최신 태그에 게시한다고 생각합니다).

@lshadler 우리는 최고의 접근 방식을 찾기 위해 잠시 동안 이것과 짝을

@bmuenzenmeyer 접근 방식에 대한 개요를 알려

구현에 대해 더 많이 생각할수록 v11이 필요하고 버전 및 게시 명령에 더 많은 컨텍스트가 추가되어야 한다고 생각합니다.

이전 릴리스의 경우 changelog, afterVersion 및 최신 릴리스 중에 호출된 모든 또는 해당 후크와 함께 실행할 전체 최신 파이프라인이 필요합니다.

다음 릴리스에는 afterVersion 게시 이후에 게시 흐름이 최신 버전과 동일한 버전이 되도록 해야 합니다. 그것도 v11의 일부가 될 수 있습니다. 유사한 자동화를 추가할 수 있도록 최신 워크플로와 일치해야 합니다.

카나리아에 대해 커밋된 것이 없으며 이미 카나리아 후크를 탭하여 더 많은 작업을 수행할 수 있으므로 카나리아 워크플로는 동일하게 유지될 수 있습니다.

안녕하세요 여러분, 작년의 미친 일로 불행히도이 문제는 저에게서 멀어졌습니다.

다양한 접근 방식과 관련하여 이러한 기능이 해결하는 다양한 사용 사례를 고려하는 것이 도움이 될 수 있다고 생각합니다. 제 생각에는 2가지 사용 사례를 볼 수 있습니다.

• (1) 이전 브랜치에 대한 장기 지원(예: 이전 주요 버전)
• (2) 특정 버전에 대한 단기 지원(예: 핫픽스)

이 대화를 바탕으로 각 사용 사례에 대해 고유한 접근 방식을 갖는 것이 합리적이라고 생각합니다.

(1) 브랜치/릴리스 트랙의 장기적인 지원을 위해서는 versionBranches 가 해결될 수 있어야 한다고 생각합니다. 마이너 버전에 대해 이 동작을 확장하려는 경우(몇몇이 위에서 언급한 것처럼) 해당 기능이 향상될 수 있습니다.

(2) 단기 지원/핫픽스의 경우 위의 스레드를 기반으로 사용자가 항상 semver의 빌드 부분을 사용하여 핫픽스 릴리스를 생성하는 표준 방법이 있어야 한다고 생각합니다. 이는 코드 소유자가 사용하고 몇 가지 복잡한 코너 케이스 시나리오를 피할 수 있는 일관된 동작을 제공합니다. 이 경우 새로운 핫픽스 명령과 후크를 사용할 수 있다고 생각합니다. 이것은 뚜렷한 향상이 될 수 있습니다. 일반적으로 소비자가 가능한 경우 최신 버전을 사용하도록 권장해야 하므로 이 사용 사례는 비교적 드물어야 합니다.

edit _(단기 사용 사례의 경우 잠재적으로 versionBranches 구성을 확장하여 version- 분기에 대한 semver 레이블을 준수할지 또는 항상 활용하는지 여부를 나타내는 매개변수/토글/플래그를 허용할 수 있습니다. semver의 일부를 빌드하고 해당 분기에 대한 레이블을 무시)_

이 2가지 외에 고려해야 할 다른 사용 사례가 있습니까?

다른 사용 사례에 대해 다른 접근 방식을 고려해야 합니까?

(또한, 나는 여전히 이러한 변경 사항 중 일부를 도울 수 있지만 다른 사람이 이에 대한 변경 사항을 채택하는 것을 차단하고 싶지는 않습니다)

또한 분기 패턴에 대한 접선적 사고:

auto는 릴리스에 대한 git 태그(릴리스)를 생성합니다. 이것은 유효한 git ref가 github에 푸시되었음을 의미합니다. 단기 지원(예: 단기 분기/핫픽스 분기) 사용 사례의 경우 릴리스/git 태그가 푸시된 후 사용자가 단기 분기를 삭제할 수 있음을 의미합니다.

• 다음 태그가 있는 마스터 브랜치가 주어집니다.
  <ul> <li>(tag: v1.3.0) (master)<br /> | </li> <li>(tag: v1.2.3)<br />

수명이 짧은 분기의 경우 기능을 추가할 때 분기 패턴 위에 문서화하는 것이 좋습니다. 나는 개인적으로 많은 사람들이 당신이 브랜치를 삭제할 수 있고 여전히 새로운 커밋에 대한 참조를 가지고 있다는 사실을 알지 못한다는 것을 발견했습니다. 이는 다른 프로젝트에서 수명이 짧은 브랜치의 혼란을 줄이는 데 도움이 될 수 있습니다.

저는 최근에 semver의 빌드 부분을 활용하여 빌드를 만드는 코드를 가지고 놀고 있었습니다. 그렇게 하는 동안 최신 github 릴리스가 반드시 최신/최고 시맨틱 버전이 아닌 사용 사례를 발견했습니다.

예를 들어, https://github.com/intuit/auto/issues/1054#issuecomment -780286683에 언급된 예에서 최신 github 릴리스는 최고 이후에 일시적으로 생성되었기 때문에 v1.2.3+1 로 표시됩니다. 버전 의미 버전: v1.3.0 .

코드 참조 getLatestRelease 꽤 많은 부분이 있기 때문에 파이프라인이 from 매개변수를 명시적으로 설정하지 않으면 다양한 동작이 발생할 수 있습니다. 즉:

• 릴리스 정보에 포함된 내용
• 이전 버전은 다음과 같이 계산됩니다.
• HEAD 커밋에서 최신 github 릴리스에 연결할 수 없는 경우 잠재적으로 기능이 중단됨

테스트하지는 않았지만 이러한 유형의 시나리오는 기존 versionBranches 동작을 통해서도 도달할 수 있다고 생각합니다. 나는 이것이 git 태그/github 릴리스를 생성해야 하는 흐름에 대한 주석과 관련이 있다고 생각합니다.

대답할 마지막 질문은 여전히 핫픽스 후크 또는 호출 버전+게시 후크입니다. 우리는 옵션 2를 수행하고 버전+게시를 호출합니다(이는 실수로 최신 태그에 게시한다고 생각합니다).

해결 측면에서 이 문제는 getLatestRelease 논리를 다음 중 하나로 대체하여 후크 리팩토링과 독립적으로 해결할 수 있습니다.

• (1) listReleases 사용하여 github 릴리스를 가져온 다음 도달할 수 있는 가장 높은 릴리스 버전(프리릴리즈 또는 빌드 파트 없음)을 찾기 위해 정렬합니다.
• (2) 또는 git 태그를 가져온 다음 도달 가능한 가장 높은 릴리스 버전(시험판 또는 빌드 부품 없음)을 찾기 위해 정렬합니다.

여기서 차이점은 auto 이 토론 https://github.com/intuit/auto/discussions/1867#discussioncomment -684192와 관련된 github 릴리스 또는 git 태그를 진실의 소스로 보는지 여부입니다.

나는 처음에 (2) 쪽으로 기울고,

• (a) 우리는 궁극적으로 git ref(태그) 뒤에 있으며 github 릴리스의 다른 요소가 아닙니다.
• (b) 네트워크 호출 수를 줄입니다.

@힙스터스무디 ,
getLatestRelease 로직을 수정해야 하는 경우 (1) github 릴리스 사용 vs (2) git 태그 사용 vs (3) 다른 것에 대해 어떻게 생각하십니까?

예, 다중 패키지 자동이 작동하려면 모든 최신 GitHub 릴리스 항목을 태그로 리팩터링해야 합니다. 2 는 이 작업을 완료하기 위해 사용할 수 있는 옵션입니다.