메인 콘텐츠로 바로가기

Capgo Semver Tester

Capacitor 앱 업데이트의 시맨틱 버전 호환성을 확인하세요.

Capgo에 설치된 앱이 보고하는 버전, config 또는 네이티브 앱 메타데이터에서.

두 개의 의미론적 버전을 입력하여 비교를 보려면

"로컬 버전"이란 무엇인가요?

로컬 버전은 기기에서 업데이트 서버에 배ंडल을 요청할 때 기기에 이미 설치된 버전입니다. Capacitor 앱에서, 그 값은 CapacitorUpdater.version 에서 가져올 수 있습니다. capacitor.config.*그 설정이 없으면 플러그인은 iOS 또는 Android의 네이티브 앱 버전으로 돌아갑니다. 그 버전을 package.json 버전으로 가정하지 마십시오. __CAPGO_KEEP_0__ config

Capacitor config

로컬 버전이 네이티브 버전과 일치하지 않을 때 사용합니다. CapacitorUpdater.version 일관된 버전을 앱이 전송할 때 사용합니다.

장점: iOS와 Android 빌드에서 동일하게 유지하기 쉽습니다.

단점: 설정 파일을 업데이트하기忘记하면 native 릴리즈 전에 잘못된 버전을 보고할 수 있습니다.

Native 앱 버전

iOS나 Android와 같은 플랫폼 버전을 사용하세요. CFBundleShortVersionString 장점: versionName.

TestFlight, App Store, Play Store, 또는 내부 테스트에서 설치한 바이너리와 일치합니다. 단점:

변경은 native 빌드가 필요하고 릴리즈 설정이 플랫폼에 따라 달라질 수 있습니다. Bundle targeting

__CAPGO_KEEP_0__

remote bundle versions, channel semver 규칙, 또는 업로드 제약 조건과 비교하십시오. --native-version.

장점: 최신 네이티브 code이 필요하지만 이전 앱 바이너리에 전송되는 자바스크립트를 보내지 않도록 방지합니다.

단점: 규칙이 너무 엄격하면 유효한 업데이트를 차단할 수 있습니다. 채널 또는 배포 메타데이터를 조정할 때까지.

이 테스터에 대해, 장치가 로컬로 보고하는 버전을 입력하고, Capgo이 전달하고 싶은 원격 배포 버전과 비교하십시오.

Capgo이 왜 Semantic Versioning을 사용하는가

Semantic Versioning 소프트웨어 개발에서 가장 널리 채택된 버전 관리 표준입니다. semver를 사용하여 Capgo은 Capacitor 앱에 대한 실시간 업데이트를 안전하고 호환되게 전달할 수 있습니다.

semver 표준은 Capgo이 각 업데이트에 포함된 변경 사항을 정확하게 이해할 수 있도록 합니다:

  • 패치 업데이트(1.0.0 → 1.0.1): 버그 수정, 자동으로 적용할 수 있습니다.
  • __CAPGO_KEEP_0__의 미묘한 업데이트스 (1.0.0 → 1.1.0): 새로운 기능, 이전 버전과 호환
  • __CAPGO_KEEP_0__의 주요 업데이트스 (1.0.0 → 2.0.0): 파괴적인 변경, 네이티브 앱 스토어 릴리스가 필요

Capgo가 네이티브 code에 불일치한 업데이트를 보내지 못하도록 하여, 사용자들이 앱이 충돌하지 않도록 보호하고 앱이 안정적으로 유지되도록 합니다.

flexible Semver 전략: 기본 버전 관리를 넘어

semver는 핵심 형식에 대해 엄격하지만, 팀의 필요에 따라 확장할 수 있습니다. pre-release 식별자빌드 메타데이터:

🏷️ 빌드 메타데이터 (+) - 외관적인 층

1.2.0+20240315.142530
배포 추적을 위한 타임스탬프
1.2.0+ui.refresh.어두운모드
디자인 팀을 위한 UI 업데이트 설명
1.2.0+build.4729.commit.a1b2c3d
CI/CD 빌드 번호 및 Git 커밋

중요: 버전 순위에서 빌드 메타데이터는 무시됩니다 - 1.2.0+anything equals 1.2.0 for Capgo의 업데이트 논리.

🔧 미리 출시 식별자 (-) - 개발 채널

1.3.0-베타.1
베타 테스트 채널
1.3.0-핫픽스.결제
긴급 수정 branch
1.3.0-feature.newapi
기능 branch 테스트

주의: 미리 출시 버전은 낮은 우선 순위 - 1.3.0-beta.1 < 1.3.0

🎯 하이브리드 접근 방식 - 양쪽의 최고

1.3.0-rc.1+ui.redesign.20240315
UI 메타데이터와 타임스탬프가 포함된 릴리즈 후보

실제 Semver 사용 사례 및 팀 전략

🚀 스타트업 / 빠른 개발

0.1.0 - 첫 MVP 출시
0.2.0-beta.1 - 새로운 기능 테스트
0.2.0+ui.v2 - UI redesign metadata
1.0.0 - 생산 준비 완료

0.x.x 버전을 사용하여 1.0 이전 개발, 디자인 추적 메타데이터

🏢 기업 / 규제

2.1.0 → 4분기 릴리즈
2.1.1+sec.patch.cve2024 → 보안 패치 추적
2.2.0-rc.1+audit.ready → 사전 감사 릴리즈 후보

strict semver와 규정 준수 메타데이터

🎮 게임 / 창의적 앱

1.0.0+season.winter.2024 → 계절 콘텐츠
1.1.0+event.halloween → 이벤트 기반 기능
1.2.0+assets.hd.remaster → 자산 업데이트

콘텐츠 추적을 위한 창조적 메타데이터

⚡️ 긴급 수정 전략

1.2.0 → 현재 운영
1.2.1-hotfix.payment → 심각한 버그 수정
1.2.1+urgent.20240315.1430 → 타임스탬프와 함께 릴리즈

테스트를 위한 미리 릴리즈, 배포 추적을 위한 메타데이터

🌍 다중 플랫폼 전략

1.3.0+ios.optimized → iOS 전용 최적화
1.3.0+android.material3 → 안드로이드 디자인 업데이트
1.3.0+web.pwa.ready → PWA 기능

같은 버전, 플랫폼에 따른 메타데이터

🔄 CI/CD 통합

1.4.0-alpha.1+build.123 → 자동화된 미리 출시
1.4.0+deploy.staging.456 → 스테이징 배포
1.4.0+prod.final.789 → 프로덕션 배포

배포와 함께 자동화된 버전 관리

💡 프로 팁:
  • 빌드 메타데이터 (+) 사용하여 추적, 타임스탬프, 또는 호환성에 영향을 주지 않는 외관 정보를 추적하세요
  • 개발 채널이 다른 업데이트 순위가 필요한 경우(-) 프리 리리즈 식별자 사용
  • 최대 유연성을 위해両方 combination: 1.2.0-beta.1+ui.dark.theme.20240315
  • 중요한 점: Capgo는 semver 순위 규칙을 존중하므로 채널 전략을 계획하세요

중요한 점: Capgo는 엄격한 의미 버전 관리를 사용합니다

Unlike npm's semver implementation, Capgo follows the official SemVer specification strictly. npm's node-semver has known deviations from the spec, which can cause unexpected behavior.

예를 들어, npm는 버전과 같은 버전을 처리합니다 1.0.0-alpha.1 규격에 따라 다른 방식으로. 자세한 내용은 보고된 문제 이미 병합되지 않은 시도한 수정 유효한 의미론적 버전

✓ 표준 릴리스

1.0.0 ✓ 프리 리리스
2.1.3-alpha ✓ 숫자가 포함된 프리 리리스
1.0.0-beta.1 ✓ 빌드 메타데이터
1.0.0+build.1 ✓ 완전한 버전
1.0.0-rc.1+build.1 유효하지 않은 의미론적 버전

See our

v1.0.0 ✗ 'v'의 앞에 leading이 허용되지 않습니다.
1.0 ✗ 패치 버전이 누락되었습니다.
1.0.0.0 ✗ 버전의 부분이 너무 많습니다.
1.0.0- ✗ 프리 리리스 버전이 비어 있습니다.
1.0.0+ ✗ 빌드 메타데이터가 비어 있습니다.

Capgo 업데이트 동작

패치 업데이트는 자동으로 적용됩니다. (1.0.0 → 1.0.1)
소수점 업데이트는 채널 설정이 필요합니다. (1.0.0 → 1.1.0)
주수 업데이트는 네이티브 앱 스토어 릴리스가 필요합니다. (1.0.0 → 2.0.0)
프리 리리스 버전은 명시적인 설정이 필요합니다.

이 도구는 공식 Semantic Versioning 명세를 따릅니다. 비교 npm의 구현과 다릅니다.