함수 버전과 호환성

함수의 게시 버전은 게시자가 정하며 생성 후 수정하거나 덮어쓸 수 없습니다. 기존 소비자가 계속 같은 입력과 결과 계약을 사용할 수 있는지에 따라 버전을 선택해야 합니다.

호환 변경과 계약 변경

선택 입력 추가, 기대 동작을 바꾸지 않는 성능 개선이나 버그 수정은 호환 가능한 변경입니다. 필수 입력 추가, Integer 결과를 String으로 바꾸는 변경이나 함수 삭제는 소비자의 수정을 요구할 수 있습니다.

내부 구현만 바뀌어도 소비자가 기대한 동작이 달라지면 호환성에 영향을 줍니다. 형식 검사 통과만으로 Minor나 Patch가 안전하다고 판단할 수는 없습니다.

의미적 버전

버전은 Major.Minor.Patch인 X.Y.Z 형식의 음수가 아닌 정수로 구성합니다. 1.2.3-rc1처럼 사전 릴리스 식별자를 붙일 수도 있습니다.

0.y.z 단계에서는 비호환 변경을 Minor, 호환 변경을 Patch로 내는 관행이 있습니다. 실제 소비 앱이 자동 업그레이드를 허용하는 범위와는 구분해야 합니다.

게시 전 자동 검사

다음 변경에는 호환성 경고가 발생합니다.

• 함수 삭제
• 선택 입력을 포함한 입력 제거
• 입력 순서 변경
• 필수 입력 추가
• Integer에서 String 같은 입력 타입 변경. Integer에서 Float 같은 숫자 타입 확대도 경고 대상입니다.
• String에서 선택적 String 같은 결과 타입 변경

초기 개발 단계가 아니라면 이런 경고가 있을 때 Major 릴리스를 검토해야 합니다. 다만 검사는 모든 내부 동작 변경을 찾아내지 못하므로 사용자 계약도 검토해야 합니다.

사용자 지정 타입의 선택 필드

내부 타입 표현이 선택 필드 정보를 충분히 담지 못하여 사용자 지정 타입의 필드를 추가하거나 제거하면 선택 필드도 경고할 수 있습니다. TS의 quantity?: Integer, Python의 quantity: Integer = 0 같은 필드가 해당합니다.

선택적인 출력 필드 제거와 입력 필드 추가에서 불필요한 경고를 줄이는 개선은 예정되어 있습니다. 선택 입력 필드를 제거하는 경우에는 소비자가 그 값에 의미가 있다고 기대할 수 있으므로 계속 경고 대상입니다.

안정 태그와 소비자 보호

>=1.2.3 <2.0.0 같은 버전 범위를 사용하는 운영 앱은 새 안정 버전을 자동으로 받을 수 있습니다. 보호 브랜치의 저장소 설정에서 안정 버전 태그를 제한하여 검토 없이 게시하는 것을 막을 수 있습니다.

잘못된 Minor나 Patch의 복구

예를 들어 String 입력 하나를 받던 myFunction 1.0.0에 필수 입력을 추가하고 실수로 1.1.0으로 게시했다고 가정합니다. 기존 계약을 복원하려면 추가한 필수 입력을 제거한 변경을 새 버전 1.2.0으로 게시할 수 있습니다. 이미 게시한 1.1.0 자체를 수정하는 방식은 아닙니다.

마지막 릴리스가 실패하여 자동 호환성 검사를 비교할 수 없으면 custom tag로 마지막 성공 태그와 비교합니다. 아직 게시 중이라면 완료를 기다려야 합니다.

브랜치 버전은 목표 안정 버전과 미리보기 버전을 구분합니다. 전용 배포와 Marketplace는 실행 가능한 버전 및 설치 시 버전 해소에 추가 조건이 있습니다.