Go의 주요 버전은 엉망입니다. 한 팬으로부터 왔습니다.

우정 Go’s Major Versioning Sucks – From a Fanboy이 Qvault에 처음으로 등장했다.
나는 보통 바둑 도구 사슬의 강성 팬이다.사실 우리가 사용하는 것은 front and backend at Qvault이다.전체 언어에 표준화된 격식, 심사와 테스트가 있으니 정말 좋다.내가 직면한 첫 번째 진정한 비판은 Go모듈이 주요 버전을 처리하는 방식이다.그것은 지나치게 자신의 의견을 고집하기 때문에 많은 경우에 개발 속도를 늦출 수 있다.

"Go Mod" 복습

Go 모듈 및 관련 명령 go mod과 go get은 Go와 NPM, Yarn의 등가물로 간주할 수 있습니다.Go 도구 체인은 의존 관계와 코드 집합에 의존하는 버전을 관리하는 방법을 제공합니다.
가장 흔히 볼 수 있는 조작 중 하나는 기존 모듈의 의존항을 업데이트하는 것이다.예:

# update all dependencies
go get -u ./...

# add missing and remove unused dependencies
go mod tidy

# save all dependency code in the project's "vendor" folder
go mod vendor

의미 버전 제어

Go 모듈은git 태그와 의미 버전 제어를 사용하여 관련 모듈과 호환되는 의존 항목의 버전을 추적합니다.의미 버전 제어는 버전 번호를 포맷하는 방법입니다. v{MAJOR}.{MINOR}.{PATCH}으로 보입니다.예를 들어, v1.2.3.
각 숫자는 다음 기준에 따라 증가합니다.

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.

패키지 문제

Go는 v0 및 v1 이외의 모든 버전은 모듈 경로에서 주 버전을 사용해야 한다고 결정했습니다.이 점을 실현할 수 있는 두 가지 방법이 있다.
Go Blog의 예제에는 다음과 같은 첫 번째 권장 사항이 나와 있습니다.

To start development on v2 of github.com/googleapis/gax-go, we’ll create a new v2/ directory and copy our package into it.

다시 말하면 모든 주요 버전에 대해 우리는 전체 코드 라이브러리의 새로운 복사본을 유지하는 것을 장려받는다.만약 예비 모듈 사용자가 당신의 소프트웨어 패키지를 사용할 수 있기를 원한다면, 이것도 유일한 방법이다.
두 번째 방법은 go.mod에서 모듈의 이름을 바꾸는 것이다.예를 들어, module github.com/lane-c-wagner/go-tinydate은 module github.com/lane-c-wagner/go-tinydate/v2이 됩니다.이것은 비교적 오래된 버전의 Go에 적용되지 않는 것 외에, 나는 그것이 문제가 있다는 것을 발견했다. 왜냐하면 모듈 이름에 관한 가장 유용한 것 중 하나인 파일 경로를 반영했기 때문이다.

패키지 솔루션

패키지 관리자가 git 태그를 업데이트하기만 하면 주 버전을 지정할 수 있고 모듈 이름을 변경할 필요가 없습니다.두 가지 진리의 원천은 필요 없다.go get CLI에 경고 또는 프롬프트를 추가하여 보안 업데이트를 수행할 수 있습니다.우리는 불필요한 시간 소모 정책을 추가할 필요가 없다.

클라이언트 문제

새 버전의 의존항이 발표되었을 때, 우리는 최신 것을 얻기 위한 간단한 명령을 가지고 있다. go get -u.문제는 이 명령이 새 주 버전으로 자동으로 업데이트되지 않는다는 것입니다.그것은 새로운 변경 사항과 패치만 다운로드할 수 있다.새로운 주요 버전이 존재한다는 것을 알리는 컨트롤러 메시지도 없습니다!
즉, 자동으로 업데이트되지 않는 이유는 명확하고 공평하게 말하면 그 이유는 충분하다.

If an old package and a new package have the same import path, the new package must be backwards compatible with the old package.

Import compatibility rule

다시 말하면 우리는 중단 변경을 할 때만 주요 버전을 추가해야 하며, 중단 변경을 하면 같은 가져오기 경로를 가질 수 없다.비록 이것은 일리가 있지만, 나는 간단한 컨트롤러 경고가 지역 사회에서 번거로운 업데이트 정책을 강제로 집행하는 것이 아니라 더 좋은 해결 방안이 될 것이라고 생각한다.
클라이언트의 또 다른 문제는 go.mod을 업데이트해야 할 뿐만 아니라 실제로 코드 라이브러리를 통해 grep을 업데이트하고 모든 가져오는 문장을 새로운 주요 버전으로 변경해야 한다는 것입니다.

Users who wanted to use v2 had to change their package imports and module requirements to github.com/googleapis/gax-go/v2.

몇 가지 간단한 CLI 명령을 사용하여 최신 의존 항목을 가져오는 대신 코드 자체를 변경하고 있습니다.

클라이언트 솔루션

go get -u은 주요 버전을 업데이트하기 위한 추가 명령행 로고가 있어야 하며, 업데이트된 주요 버전이 아직 없다는 경고를 기본적으로 표시해야 합니다.
가져오기 경로는 주요 버전 간에 변경해서는 안 됩니다.

왜 이게 나한테 엉망이야?

통상적으로 나는 특정 분야의 논리를 가진 패키지를 구축하고 내가 일하는 작은 회사에서만 서비스를 제공하기를 바란다.예를 들어 우리는 struct{}이 우리 시스템에서 사용하는 흔한 실체에 대한 정의를 포함하는 환매 협의를 가지고 있다.
때때로 우리는 그 구조 정의를 뒤로 호환되지 않는 변경을 해야 한다.만약 그것이 소스 라이브러리라면, 우리는 자주 변경하지 않겠지만, 그것은 내부적이고, 모든 의존 관계를 알고 있기 때문에, 우리는 정기적으로 내보내는 필드의 이름을 변경할 것이다.우리가 개명한 것은 우리가 처음에 나쁜 이름을 선택했기 때문이 아니라 초창기 기업의 업무 수요 변화가 신속하기 때문이다.
이것은 중대한 버전 변경이 자주 발생한다는 것을 의미한다.어떤 사람들은 우리가 v0에만 관심을 가져야 한다고 말한다. 이것은 합리적인 해결 방안이다.문제는 대량의 서비스에 사용되는 생산 패키지들이다.우리는 승리를 원한다.
Go는 주요 버전을 업데이트하는 것을 이렇게 번거롭게 합니다. 대부분의 경우 주요 버전을 추가해야 할 때 부차적인 버전만 추가합니다.우리는 적당한 버전 제어 방안을 따르기를 원하지만, 개발 과정에서 불필요한 절차를 추가하고 싶지 않다.

야, 알았어.

나는 왜 이런 결정을 내렸는지 이해한다. 나는 심지어 많은 상황에서 이런 결정들은 모두 위대한 결정이라고 생각한다.모든 개원이나 대중을 위한 모듈에 대해 말하자면, 이것은 매우 의미가 있다.바둑 도구 체인은 양호한 API 설계를 장려하기 위해 엄격한 규칙을 집행하고 있다.
공공 API를 더욱 좋게 하기 위해서, 그들은 양호한'로컬'패키지 설계를 불필요한 어려움으로 만들었다.
CLI에서 새 주요 버전을 쉽게 검색할 수 있는 open issue on Github이 있습니다.만약 당신이 흥미가 있다면 한번 보세요.
Go는 여전히 가장 좋은 도구 체인과 생태계를 가지고 있다.NPM과 PIP는 그것을 빨아먹을 수 있다.
만약 네가 동의하지 않는다면, 나는 트위터에 있다.

읽어주셔서 감사합니다!

질문이나 의견이 있으면 트위터에서 팔로우하세요
coding courses on our new platform을 예로 들다
Subscribe~우리의 시사통신, 더 많은 프로그래밍 기사 얻기