Capgo Semver Tester
__CAPGO_KEEP_0__ 버전 확인기
"네이티브 기본 버전"이란 무엇인가요
네이티브 기본 버전은 Capgo로 전송되는 네이티브 앱 버전입니다. 장치가 업데이트 서버에 배ंडल을 요청할 때 Capgo 앱에서 해당 값은
version_build when the device asks the update server for a bundle. In a Capacitor app, that value can come from
CapacitorUpdater.version 가 올 수 있습니다. 만약 해당 설정이
없다면 플러그인은 iOS 또는 Android에서 네이티브 앱 버전을 가져옵니다. 버전이 __CAPGO_KEEP_0__ 앱의 버전이 아닙니다. 빌드가 해당 값을 config 또는 네이티브 메타데이터로 복사하지 않는 한. capacitor.config.*__CAPGO_KEEP_0__는 여전히 사용됩니다 package.json
__CAPGO_KEEP_0__ still uses
Capgo still uses version_name 다운로드 한 패키지를 현재 설치한 패키지인지 알기 위해. major, minorChannel semver 정책
patch , 및 version_build.
remote 패키지를 Capacitor config
설정 CapacitorUpdater.version 앱이 전송한 특정 버전을 원할 때.
장점: iOS 및 Android 빌드에서 동일한 것을 유지하기 쉽다.
단점: 업데이트를忘고 네이티브 릴리즈 전에 stale config를 사용하면 올바른 버전을 보고할 수 있다.
네이티브 앱 버전
플랫폼 버전을 사용하십시오, 예를 들어 iOS CFBundleShortVersionString 또는 안드로이드
versionName.
장점: TestFlight, App Store, Play Store, 또는 내부 테스트에서 설치한 바이너리 사용자와 일치합니다.
단점: 릴리즈 설정이 드리프트하는 경우 플랫폼에 따라 달라질 수 있으므로 변경이 필요합니다.
대분류
Compare it with remote bundle versions, channel semver rules, or upload constraints such as --native-version.
장점: 최신 네이티브 code이 필요로 하는 자바스크립트를 보내지 않도록 방지합니다.
단점: 규칙이 너무 엄격하면 채널 또는 대분류 메타데이터를 조정할 때까지 유효한 업데이트를 차단할 수 있습니다.
이 테스터에 대해, 기기에서 보내는 네이티브 베이스 라인 입력하세요 version_build그것을 Capgo와 원격으로 배포한 버전과 비교합니다.
원하는 Capgo 배포 버전입니다.
Capgo이 왜 Semantic Versioning을 사용하는지
Semantic Versioning 소프트웨어 개발에서 가장 널리 채택된 버전 관리 표준입니다. semver를 사용하여 Capgo은 앱에 대한 live 업데이트를 안전하게 전달할 수 있으며, 앱의 Capacitor 호환성을 보장합니다.
semver 표준은 각 업데이트에 포함된 변경 사항을 정확하게 이해할 수 있도록 Capgo에게 허용합니다:
- 패치 업데이트(1.0.0 → 1.0.1): 버그 수정, 자동으로 적용할 수 있습니다.
- 마이너 업데이트(1.0.0 → 1.1.0): 새로운 기능, 뒤로 호환됩니다.
- 메이저 업데이트(1.0.0 → 2.0.0): 파괴적인 변경, 네이티브 앱 스토어 릴리스가 필요합니다.
이러한 변경은 Capgo가 네이티브 code에 불일치한 업데이트를 전송하지 않도록 하며, 사용자에게 충돌이 발생하지 않도록하고 앱이 안정적으로 유지되도록합니다.
flexible Semver 전략: 기본 버전 관리를 넘어
semver는 핵심 형식에 대해 엄격하지만, 팀의 요구에 맞게 확장할 수 있습니다. pre-release 식별자 및 빌드 메타데이터:
🏷️ 빌드 메타데이터 (+) - "외관" layer
중요: 버전 우선 순위에서 __CAPGO_KEEP_0__의 업데이트 논리에서 메타데이터는 무시됩니다.
1.2.0+anything equals 1.2.0 위의 Capgo의 업데이트 논리에 대해.
🔧 - 개발 채널 (-)
주의: 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 - 프로덕션 준비0.x.x를 사용하여 1.0 이전 개발, 디자인 추적을 위한 메타데이터
🏢 기업 / 규제
2.1.0 → 분기별 릴리즈2.1.1+sec.patch.cve2024 → 2.2.0-rc.1+audit.ready → Strict semver with compliance metadata
🎮
1.0.0+season.winter.2024 → 1.1.0+event.halloween → 1.2.0+assets.hd.remaster → Creative metadata for content tracking
⚡
1.2.0 → 1.2.1-hotfix.payment → 1.2.1+urgent.20240315.1430 → __CAPGO_KEEP_0__
__CAPGO_KEEP_0__
1.3.0+ios.optimized 🌍 다중 플랫폼 전략1.3.0+android.material3 → iOS 전용 최적화1.3.0+web.pwa.ready → 안드로이드 디자인 업데이트→ PWA 기능
같은 버전, 플랫폼별 메타데이터
1.4.0-alpha.1+build.123 🔄 CI/CD 통합1.4.0+deploy.staging.456 → 자동화된 프리 리리즈1.4.0+prod.final.789 → 스테이징 배포→ 프로덕션 배포
- __CAPGO_KEEP_0__을 사용하여 빌드 메타데이터 (+)로 추적, 시간戳, 또는 호환성에 영향을 주지 않는 외관 정보를 추적하세요.
- __CAPGO_KEEP_0__을 사용하여 개발 채널이 다른 업데이트순위가 필요할 때(-) 프리리리즈 식별자를 사용하세요.
- 두 가지를 모두 사용하여 최대의 유연성을 얻으세요.
1.2.0-beta.1+ui.dark.theme.20240315 - 주의: Capgo은 semver 순위 규칙을 준수하므로 채널 전략을 계획하세요.
중요: Capgo은 엄격한 의미 버전 관리를 사용합니다.
npm의 semver implementation과 달리 Capgo은 공식 SemVer 규격을 엄격하게 따릅니다. npm의 node-semver는 규격에서 알려진 편차를 가지고 있어 예상치 못한 동작을 유발할 수 있습니다.
예를 들어 npm은 버전을 다음과 같이 다르게 처리합니다. 1.0.0-alpha.1
differently than the specification requires. See our
reported issue and
attempted fix that was never merged.
정상 버전
1.0.0
✓ 표준 릴리스
2.1.3-alpha
✓ 프리 리리즈
1.0.0-beta.1
✓ 숫자가 포함된 프리 리리즈
1.0.0+build.1
✓ 빌드 메타데이터
1.0.0-rc.1+build.1
✓ 완전한 버전
잘못된 정상 버전
v1.0.0
✗ 'v'로 시작할 수 없습니다.
1.0
✗ 패치 버전이 누락되었습니다.
1.0.0.0
✗ 버전 파트가 너무 많습니다.
1.0.0-
✗ 프리 리리즈가 비어 있습니다.
1.0.0+
✗ 빌드 메타데이터가 비어 있습니다.
Capgo 업데이트 동작
이 도구는 공식 Semantic Versioning 사양을 따릅니다. npm의 implementation과는 달리.