메이저 버전 업데이트 개발하기

메이저 버전 업데이트 개발하기 (Developing a major version update)

만드는 새로운 버전의 변경 사항이 모듈 사용자에게 하위 호환성(backward compatibility)을 보장할 수 없게 된다면, 메이저 버전(major version)으로 업데이트해야 합니다. 예를 들어 모듈의 공개 API를 바꿔서 이전 버전의 모듈을 쓰던 클라이언트 코드를 깨뜨리게 된다면 이 변경을 하게 되죠.

출처: Go 공식 문서

참고: 메이저, 마이너(minor), 패치(patch), 사전 릴리스(pre-release) 같은 각 릴리스 유형은 모듈 사용자에게 서로 다른 의미가 있어요. 사용자들은 이 차이를 바탕으로 자신의 코드에 릴리스가 어느 정도의 위험을 뜻하는지 파악합니다. 다시 말해 릴리스를 준비할 때는 그 버전 번호가 이전 릴리스 이후의 변경 성격을 정확히 반영하도록 해야 합니다. 버전 번호에 대한 자세한 내용은 Module version numbering을 참고하세요.

참고 자료 (See also)

메이저 버전 업데이트를 고려할 때

새 메이저 버전으로의 업데이트는 정말 필요할 때만 해야 합니다. 메이저 버전 업데이트는 여러분과 모듈 사용자 모두에게 큰 변동(churn)을 의미하거든요. 메이저 버전 업데이트를 고려할 때는 다음을 생각해 보세요:

  • 새 메이저 버전을 릴리스하는 것이 이전 메이저 버전 지원에 어떤 의미인지 사용자에게 분명히 알리세요. 이전 버전이 더 이상 지원되지 않는 건가요? 이전처럼 계속 지원되나요? 버그 수정을 포함해 이전 버전을 계속 유지보수할 건가요?
  • 두 버전(구버전과 신버전)의 유지보수를 맡을 준비를 하세요. 예를 들어 한쪽에서 버그를 고치면 흔히 그 수정을 다른 쪽에도 포팅하게 됩니다.
  • 새 메이저 버전은 의존성 관리 관점에서 완전히 새로운 모듈이라는 점을 기억하세요. 사용자들은 릴리스 후 단순히 업그레이드하는 것이 아니라 새 모듈을 사용하도록 업데이트해야 합니다. 그 이유는 새 메이저 버전이 이전 메이저 버전과 다른 모듈 경로를 갖기 때문이에요. 예를 들어 모듈 경로가 example.com/mymodule인 모듈의 v2 버전은 모듈 경로가 example.com/mymodule/v2가 됩니다.
  • 새 메이저 버전을 개발할 때는, 새 모듈의 패키지를 import 하는 모든 곳의 import 경로도 업데이트해야 합니다. 모듈 사용자들도 새 메이저 버전으로 업그레이드하려면 자기 import 경로를 업데이트해야 하고요.

메이저 릴리스를 위한 브랜칭 (Branching for a major release)

새 메이저 버전을 개발하기 위한 소스 처리에서 가장 직관적인 접근은, 이전 메이저 버전의 최신 버전 지점에서 저장소를 브랜치(branch)하는 것입니다.

예를 들어 명령 프롬프트에서 모듈의 루트 디렉터리로 이동한 뒤, 그곳에서 새 v2 브랜치를 만들 수 있어요.

$ cd mymodule
$ git checkout -b v2
Switched to a new branch "v2"

소스를 브랜치했다면, 새 버전의 소스에 다음 변경을 해야 합니다:

  • 새 버전의 go.mod 파일에서 모듈 경로에 새 메이저 버전 번호를 이어 붙이세요. 예를 들면:
    • 기존 버전: example.com/mymodule
    • 새 버전: example.com/mymodule/v2
  • Go 코드에서, 모듈의 패키지를 import 하는 모든 패키지 경로를 업데이트해서 모듈 경로 부분에 메이저 버전 번호를 이어 붙이세요.
    • 기존 import 문: import "example.com/mymodule/package1"
    • 새 import 문: import "example.com/mymodule/v2/package1"

게시 단계는 [/doc/modules/publishing]Publishing a module을 참고하세요.

더 알아보기 (Learn more)