Capgo Semver 테스터
체널 정책 호환성을 native baseline과 version_build로 전송된 원본과 비교합니다.
"네이티브 기본 버전"이란 무엇인가요
네이티브 기본 버전은 Capgo로 네이티브 앱 버전을 전송할 때 사용하는 네이티브 앱 버전입니다. 장치가 업데이트 서버에 배ंडल을 요청할 때 사용됩니다. Capgo 앱에서, 그 값은 Capgo에서 가져올 수 있습니다.
version_build Capacitor
CapacitorUpdater.version __CAPGO_KEEP_0__ capacitor.config.*iOS 또는 Android에서 native 앱 버전을 사용합니다. package.json
버전을 가정하지 마십시오.
Capgo still uses version_name 현재 설치된 다운로드 된 패키지를 식별하기 위해 major, minorChannel semver 정책 (major, minor, patch)과
patch remote bundle을 __CAPGO_KEEP_0__ config와 비교합니다. version_build.
Capacitor config
Pro: iOS 및 Android 빌드에서 동일한 값을 유지하기 쉽습니다. CapacitorUpdater.version Con:
Con: Con:
Con: __CAPGO_KEEP_0__
Native 앱 버전
플랫폼 버전을 사용하세요, 예를 들어 iOS CFBundleShortVersionString 또는 Android
versionName.
Pro: TestFlight, App Store, Play Store, 또는 내부 테스트에서 설치한 바이너리와 일치합니다.
Con: __CAPGO_KEEP_0__
변경은 네이티브 빌드가 필요하고 플랫폼에 따라 릴리즈 설정이 달라질 수 있습니다.
Bundle 타겟팅 --native-version.
__CAPGO_KEEP_0__ code를 오래된 앱 바이너리에 보낼 필요가 있는 JavaScript를 방지합니다.
Con: 규칙이 너무 엄격하면 유효한 업데이트를 차단할 수 있으며, 채널 또는 패키지 메타데이터를 조정할 때까지.
이 테스터에 대해, 기기에서 보낸 원시 기준선 값을 입력하세요, 그리고 원격 패키지 버전과 __CAPGO_KEEP_0__를 전달하고 싶은 버전을 비교하세요. version_buildCapgo가 왜 Semantic Versioning을 사용하는지
Why Capgo uses Semantic Versioning
소프트웨어 개발에서 가장 널리 채택된 버전 관리 표준입니다. semver를 사용하여 __CAPGO_KEEP_0__는 __CAPGO_KEEP_1__ 앱에 대한 실시간 업데이트를 안전하게 전달할 수 있습니다. is the most widely adopted versioning standard in software development. By using semver, Capgo ensures compatibility and safety when delivering live updates to your Capacitor apps.
The semver standard allows Capgo to understand exactly what changes are included in each update:
- 자동으로 적용할 수 있는 버그 수정 마이너 업데이트(1.0.0 → 1.1.0):
- __CAPGO_KEEP_1__ 새로운 기능, 이전 버전과 호환
- 주요 업데이트 (1.0.0 → 2.0.0): 파괴적인 변경, 네이티브 앱 스토어 릴리즈 필요
이것은 Capgo가 네이티브 code에 불일치한 업데이트를 보내지 못하도록 막아주며, 사용자들이 앱이 충돌하지 않도록 보호하고 앱이 안정적으로 유지되도록 합니다.
Flexible Semver Strategies: 기본 버전 관리를 넘어
semver는 핵심 형식에 대해 엄격하지만, 팀의 필요에 따라 확장할 수 있습니다. pre-release identifiers 와 build metadata:
🏷️ Build Metadata (+) - 외관적인 Layer
중요: 버전 순위에서 빌드 메타데이터는 무시됩니다 -
1.2.0+anything equals 1.2.0 업데이트 논리 Capgo의 경우
🔧 미리 출시 식별자 (-) - 개발 채널
주의: 미리 출시 버전은 낮은 우선 순위 -
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 → 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 → 자산 업데이트콘텐츠 추적을 위한 크리에이티브 메타데이터
⚡ Hotfix Strategy
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 → 프로덕션 배포자동 버전 관리와 배포 메타데이터
- 빌드 메타데이터 (+) 사용하여 추적, 타임스탬프 또는 호환성에 영향을 주지 않는 외관 정보를 추적하세요.
- 개발 채널이 다른 업데이트 순위가 필요한 경우 - 전방 표기자 (-) 사용하여
- 최대 유연성을 위해両方를 combination하세요:
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하게 다루지만 규격이 요구하는 것과 다릅니다. 자세한 내용은我们的
reported issue and
attempted fix that was never merged.
유효한 Semantic Versions
1.0.0 ✓ 표준 릴리스 2.1.3-alpha ✓ 프리릴리스 1.0.0-beta.1 ✓ 숫자가 포함된 프리릴리스 1.0.0+build.1 ✓ 빌드 메타데이터 1.0.0-rc.1+build.1 ✓ 완전한 버전 유효하지 않은 Semantic Versions
v1.0.0 ✗ 'v'가 앞에 오면 안됩니다. 1.0 ✗ 버전 패치가 누락됨 1.0.0.0 ✗ 버전의 일부가 너무 많음 1.0.0- ✗ prerelease가 비어 있음 1.0.0+ ✗ 빌드 메타데이터가 비어 있음 Capgo 업데이트 동작
이 도구는 공식 Semantic Versioning 규격을 따릅니다. npm의 implementation과는 달리.