Capgo Semver 테스터
version_build로 전달된 네이티브 베이스라인과 채널 정책 호환성을 확인하세요
resolve된 채널에 할당된 bundle version입니다.
"Native Baseline Version"의 의미
Native Baseline Version은 디바이스가 업데이트 서버에 bundle을 요청할 때 Capgo로 전송되는 native app version입니다.
version_build Capacitor 앱에서 이 값은 다음에서 가져올 수 있습니다.
CapacitorUpdater.version 에서 capacitor.config.*. 해당 설정이 없으면 플러그인은 iOS 또는 Android의 native app version으로 fallback합니다. 빌드에서 해당 값을 config나 native metadata에 복사하지 않는 한, package.json
이를 사용자의 version이라고 가정하지 마세요.
Capgo는 여전히 version_name 다운로드된 bundle 중 현재 설치된 것이 무엇인지 확인하는 데 사용합니다. 다음과 같은 Channel semver 정책은 major, minor, 그리고
patch 원격 bundle을 다음 설정과 비교합니다. version_build.
Capacitor 설정
설정 CapacitorUpdater.version 앱에서 명시적인 버전 하나를 전송하고 싶을 때.
장점: iOS와 Android 빌드 간 버전을 동일하게 유지하기 쉽습니다.
단점: 네이티브 릴리스 전 업데이트를 잊으면 오래된 설정으로 인해 잘못된 버전이 보고될 수 있습니다.
네이티브 앱 버전
iOS 같은 플랫폼 버전을 사용하거나 CFBundleShortVersionString Android를 사용하면
versionName.
장점: TestFlight, App Store, Play Store 또는 내부 테스트를 통해 사용자가 설치한 바이너리와 일치합니다.
단점: 변경하려면 네이티브 빌드가 필요하며, 릴리스 설정이 달라지면 플랫폼별로 결과가 달라질 수 있습니다.
Bundle 타겟팅
원격 bundle 버전, 채널 semver 규칙, 또는 메타데이터 업로드 제약 조건(예: )과 비교해 보세요. --min-update-version. 채널은 다음을 사용해야 합니다 --disable-auto-update metadata.
장점: 새로운 네이티브 code가 필요한 JavaScript가 구형 앱 바이너리로 전송되는 것을 방지합니다.
단점: 너무 엄격한 규칙은 채널이나 bundle 메타데이터가 조정될 때까지 유효한 업데이트를 차단할 수 있습니다.
이 테스터에서는 디바이스가 전송하는 네이티브 베이스라인을 다음으로 입력하세요 version_build, 그리고 Capgo가 전달하려는 원격 bundle 버전과 비교해 보세요.
Capgo가 Semantic Versioning을 사용하는 이유
시맨틱 버저닝 소프트웨어 개발에서 가장 널리 쓰이는 버전 관리 표준입니다. semver를 사용하면 Capgo가 Capacitor 앱에 라이브 업데이트를 배포할 때 호환성과 안전성을 보장합니다.
semver 표준 덕분에 Capgo는 각 업데이트에 포함된 변경 사항을 정확히 파악할 수 있습니다:
- Patch 업데이트 (1.0.0 → 1.0.1): 버그 수정, 자동 적용해도 안전
- Minor 업데이트 (1.0.0 → 1.1.0): 새 기능 추가, 하위 호환성 유지
- Major 업데이트 (1.0.0 → 2.0.0): Breaking change 발생, 네이티브 앱 스토어 출시 필요
이렇게 하면 Capgo가 네이티브 code에 호환되지 않는 업데이트를 보내는 일이 없어, 사용자를 크래시로부터 보호하고 앱의 안정성을 유지할 수 있습니다.
유연한 Semver 전략: 기본 버저닝 그 이상
semver는 핵심 형식을 엄격히 따르지만, 팀의 필요에 맞게 다음을 사용해 확장할 수 있습니다: pre-release 식별자 및 build 메타데이터:
🏷️ Build 메타데이터(+) - '화려한' 레이어
중요: Build 메타데이터는 버전 우선순위에서 무시됩니다 -
1.2.0+anything 같음 1.2.0 Capgo의 업데이트 로직에 대해.
🔧 Pre-release 식별자 (-) - 개발 채널
참고: Pre-release 버전은 우선순위가 낮습니다 -
1.3.0-beta.1 < 1.3.0
🎯 하이브리드 방식 - 두 방식의 장점 결합
실무 Semver 사용 사례 및 팀 전략
🚀 스타트업 / 빠른 개발
0.1.0 - 첫 MVP 릴리스0.2.0-beta.1 - 신규 기능 테스트0.2.0+ui.v2 - UI 리디자인 메타데이터1.0.0 - 프로덕션 준비 완료1.0 이전 개발에는 0.x.x, 디자인 추적에는 메타데이터 사용
🏢 엔터프라이즈 / 규제 산업
2.1.0 → 분기별 릴리스2.1.1+sec.patch.cve2024 → 추적 가능한 보안 패치2.2.0-rc.1+audit.ready → 감사 전 릴리스 후보컴플라이언스 메타데이터를 포함한 엄격한 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 → Android 디자인 업데이트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 → 프로덕션 배포배포 메타데이터를 포함한 자동 버전 관리
- 호환성에 영향을 주지 않는 트래킹, 타임스탬프, 또는 부가 정보에는 빌드 메타데이터(+)를 사용하세요
- 업데이트 우선순위 조정이 필요한 개발 채널에는 프리릴리스 식별자(-)를 사용하세요
- 최대 유연성을 위해 두 방식을 조합하세요:
1.2.0-beta.1+ui.dark.theme.20240315 - 참고: Capgo는 semver 우선순위 규칙을 따르므로, 채널 전략을 이에 맞게 계획하세요.
유효한 시맨틱 버전
1.0.0 ✓ 표준 릴리스 2.1.3-alpha ✓ 프리릴리스 1.0.0-beta.1 ✓ 번호가 포함된 Pre-release 1.0.0+build.1 ✓ 빌드 메타데이터 1.0.0-rc.1+build.1 ✓ 전체 버전 유효하지 않은 Semantic Version
v1.0.0 ✗ 앞에 'v'를 붙일 수 없음 1.0 ✗ Patch 버전 누락 1.0.0.0 ✗ 버전 구성 요소가 너무 많음 1.0.0- ✗ Pre-release 값이 비어 있음 1.0.0+ ✗ Build metadata 값이 비어 있음 Capgo Update 동작
이 도구는 공식 Semantic Versioning 명세를 npm의 구현과 달리 따릅니다.