Capgo Semver Tester

Cek konsistensi kebijakan saluran terhadap dasar native yang dikirim sebagai versi_build

Versi Dasar Asli

Versi native yang dikirim ke Capgo sebagai versi_build, dari konfigurasi atau metadata aplikasi native.

Versi Jarak Jauh

Versi paket yang ditugaskan ke saluran yang diperoleh.

Konteks Aplikasi

Platform

Pembangunan

Berjalan di Emulator

Pengaturan Saluran

iOS

Biarkan pembaruan untuk perangkat iOS

Android

Biarkan pembaruan untuk perangkat Android

Biarkan pembangunan

Biarkan pembaruan untuk pembangunan

Biarkan Emulator

Biarkan pembaruan untuk perangkat emulator

Matikan downgrade otomatis di native

Mencegah menurunkan versi ketika menjalankan native code

Matikan pembaruan otomatis

Major: menghalangi target major lebih besar dari versi build. Memungkinkan 1.2.3 -> 1.9.0, menghalangi 1.2.3 -> 2.0.0.

Masukkan dua versi semantik untuk melihat perbandingan

Apa itu "Versi Baseline Native"

Versi Baseline Native adalah versi aplikasi native yang dikirimkan ke Capgo ketika version_build perangkat meminta server pembaruan untuk mendapatkan bundle. Dalam aplikasi Capacitor, nilai tersebut dapat berasal dari CapacitorUpdater.version dalam capacitor.config.*Jika pengaturan tersebut tidak package.json ada, plugin kembali ke versi aplikasi native dari iOS atau Android. Jangan asumsikan itu adalah versi Anda kecuali Anda mengcopy nilai tersebut ke konfigurasi atau metadata native.

Capgo masih menggunakan version_name untuk mengetahui bundle yang diunduh mana yang sedang terinstal saat ini. Channel semver kebijakan seperti major, minor, dan patch bandingkan bundle remote terhadap version_build.

Capacitor konfigurasi

Set CapacitorUpdater.version ketika Anda ingin satu versi eksplisit dikirim oleh aplikasi.

Pro: mudah untuk menjaga yang sama di antara iOS dan Android build.

Kon: konfigurasi ketinggalan zaman dapat melaporkan versi yang salah jika Anda lupa untuk memperbarui sebelum rilis native.

Versi aplikasi native

Pakai versi platform, seperti iOS CFBundleShortVersionString atau Android versionName.

Pro: cocok dengan file biner yang diinstal dari TestFlight, App Store, Play Store, atau pengujian internal.

Con: mengubahnya memerlukan build native dan dapat berbeda antar platform jika pengaturan rilis bergeser.

Targeting Paket

Bandingkan dengan versi paket remote, aturan semver channel, atau konstrain unggah metadata seperti --min-update-version. Saluran harus menggunakan --disable-auto-update metadata.

Pro: mencegah mengirim JavaScript yang memerlukan native code yang lebih baru ke biner aplikasi lama.

Con: aturan yang terlalu ketat dapat menghalangi update yang valid sampai saluran atau metadata paket disesuaikan.

For tester ini, masukkan basis data asli yang perangkat kirimkan sebagai version_build, kemudian bandingkan dengan versi bundle remote yang ingin Capgo kirimkan.

Why Capgo menggunakan Semantik Versi

Semantik Versi adalah standar versi semantik yang paling luas diterima dalam pengembangan perangkat lunak. Dengan menggunakan semver, Capgo memastikan konsistensi dan keamanan ketika mengirimkan pembaruan hidup ke aplikasi Capacitor Anda.

The semver standard memungkinkan Capgo memahami secara tepat apa saja perubahan yang terkandung dalam setiap pembaruan:

Pembaruan patch (1.0.0 → 1.0.1): Pembaruan bug, aman untuk diterapkan secara otomatis
Pembaruan minor (1.0.0 → 1.1.0): Pembaruan fitur baru, konsisten ke belakang
Pembaruan mayor (1.0.0 → 2.0.0): Pembaruan perubahan besar, memerlukan rilis aplikasi native toko

Hal ini mencegah Capgo untuk pernah mengirimkan pembaruan yang tidak kompatibel ke native code, melindungi pengguna Anda dari kegagalan dan memastikan aplikasi Anda tetap stabil.

Strategi Semver Fleksibel: Lebih dari Versi Dasar

Sementara semver ketat tentang format inti, Anda dapat memperluasnya untuk kebutuhan tim Anda menggunakan identifikasi pre-release dan metadata bangunan:

🏷️ Metadata Bangunan (+) - Layer Estetika

1.2.0+20240315.142530

Timestamp untuk pelacakan pengiriman

1.2.0+ui.refresh.dark-mode

Deskripsi pembaruan UI untuk tim desain

1.2.0+build.4729.commit.a1b2c3d

Nomor bangunan CI/CD dan commit Git

Perlu diingat: Metadata pembangunan diabaikan dalam urutan versi - 1.2.0+anything setara 1.2.0 untuk Capgo's logika pembaruan.

🔧 Identifikator Pra-Rilis (-) - Saluran Pengembangan

1.3.0-beta.1

Saluran Pengujian Beta

1.3.0-hotfix.payment

Saluran Perbaikan Darurat

1.3.0-feature.newapi

Saluran Pengujian Fitur

Catatan: Versi pra-rilis memiliki prioritas lebih rendah - 1.3.0-beta.1 < 1.3.0

🎯 Pendekatan Hibrida - Terbaik dari Kedua Dunia

1.3.0-rc.1+ui.redesign.20240315

Kandidat rilis dengan metadata UI dan tanggal

Contoh Penggunaan Semver Nyata & Strategi Tim

🚀 Pengembangan Awal / Cepat

0.1.0 - Rilis MVP pertama

0.2.0-beta.1 - Pengujian fitur baru

0.2.0+ui.v2 - Metadata redesign UI

1.0.0 - Siap produksi

Gunakan 0.x.x untuk pengembangan pra-1.0, metadata untuk pengawasan desain

🏢 Bisnis / Terregulasi

2.1.0 → Rilis Kuartal

2.1.1+sec.patch.cve2024 → Perbaikan Keamanan dengan Tracking

2.2.0-rc.1+audit.ready → Kandidat Rilis Audit Sebelumnya

Semver Ketat dengan Metadata Komplian

🎮 Aplikasi Permainan/Kreatif

1.0.0+season.winter.2024 → Konten Musiman

1.1.0+event.halloween → Fitur Berdasarkan Acara

1.2.0+assets.hd.remaster → Perbarui Aset

Metadata Kreatif untuk Mengikuti Konten

⚡ Strategi Perbaikan Hotfix

1.2.0 → Produksi Saat Ini

1.2.1-hotfix.payment → Perbaikan Bug Kritis

1.2.1+urgent.20240315.1430 → Diterbitkan dengan timestamp

Pre-release untuk tes, metadata untuk pelacakan pengiriman

🌍 Strategi Multi-Platform

1.3.0+ios.optimized → Optimasi iOS khusus

1.3.0+android.material3 → Perbarui desain Android

1.3.0+web.pwa.ready → Kemampuan PWA

Sama versi, metadata spesifik platform

🔄 Integrasi CI/CD

1.4.0-alpha.1+build.123 → Rilis pre-otomatis

1.4.0+deploy.staging.456 → Pengiriman staging

1.4.0+prod.final.789 → Pengiriman produksi

Versi otomatis dengan metadata pengiriman

💡 Tips Pro:

Pakai metadata pembangunan (+) untuk melacak, tanggal, atau informasi kosmetik yang tidak mempengaruhi konsistensi
Pakai identifikasi pre-release (-) untuk saluran pengembangan yang memerlukan prioritas pembaruan yang berbeda
Combinasikan keduanya untuk fleksibilitas maksimum: 1.2.0-beta.1+ui.dark.theme.20240315
Ingatlah: Capgo menghormati aturan semver, jadi rencanakan strategi saluran Anda dengan tepat

Penting: Capgo menggunakan semver yang ketat

Berbeda dengan implementasi semver npm, Capgo mengikuti spesifikasi SemVer secara ketat. npm menggunakan node-semver yang memiliki deviasi yang diketahui dari spesifikasi, yang dapat menyebabkan perilaku yang tidak terduga

Contoh, npm menganggap versi seperti 1.0.0-alpha.1 berbeda dengan yang diperlukan oleh spesifikasi. Lihat masalah yang telah dilaporkan dan context upaya untuk memperbaikinya itu tidak pernah diintegrasikan.

Versi Semantik yang Sah

1.0.0 ✓ Rilis Standar

2.1.3-alpha ✓ Rilis Pra

1.0.0-beta.1 ✓ Rilis Pra dengan Nomor

1.0.0+build.1 ✓ Metadata Pembangunan

1.0.0-rc.1+build.1 ✓ Versi Lengkap

Versi Semantik yang Tidak Sah

v1.0.0 ✗ 'v' di awal tidak diizinkan

1.0 ✗ Tidak ada versi patch

1.0.0.0 ✗ Terlalu banyak bagian versi

1.0.0- ✗ Rilis pra kosong

1.0.0+ ✗ Metadata Bangunan Kosong

Capgo Pola Perbarui

✓ Strategi Minor memungkinkan perubahan patch di garis sama major.minor, misalnya 1.0.0 -> 1.0.1

✓ Strategi Patch memblokir 1.0.0 -> 1.0.1. Hanya memungkinkan perubahan sufiks seperti 1.0.0-beta.1 -> 1.0.0-beta.2.

✗ Strategi Major memblokir paket target dengan major yang lebih tinggi dari dasar native, misalnya 1.0.0 -> 2.0.0

⚠ Pelindung Penurunan menggunakan keutamaan semver penuh, sehingga stabil 1.0.0 lebih baru dari 1.0.0-beta.2

Ini alat mengikuti spesifikasi Versi Semantik yang resmi Tidak seperti implementasi __CAPGO_KEEP_0__. unlike npm's implementation.