Lompat ke konten utama
Capgo logo

Capgo Tester Semver

Periksa kompatibilitas kebijakan saluran terhadap dasar native yang dikirim sebagai version_build

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

Versi bundle yang ditugaskan ke saluran yang diperoleh.

Masukkan dua versi semantik untuk melihat perbandingan

Apa itu "Versi Dasar Native"

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

Capgo masih menggunakan version_name untuk mengetahui bundle yang diunduh saat ini yang terpasang. Kebijakan semver channel seperti major, minor, dan patch bandingkan bundle remote terhadap version_build.

Capacitor konfigurasi

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

Kelebihan: mudah untuk menjaga yang sama di antara pembangunan iOS dan Android.

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

Versi aplikasi native

Gunakan versi platform, seperti iOS CFBundleShortVersionString atau Android versionName.

Kelebihan: mengenai binary pengguna yang diinstal dari TestFlight, App Store, Play Store, atau pengujian internal.

Kerugian: mengubahnya memerlukan build asli dan dapat berbeda antar platform jika pengaturan rilis bergeser.

Pengaturan Bundle

Bandingkan dengan versi bundle remote, aturan semver channel, atau keterbatasan unggah seperti --native-version.

Kelebihan: mencegah mengirim JavaScript yang memerlukan native code yang lebih baru ke binary aplikasi lama.

Kerugian: aturan yang terlalu ketat dapat menghalangi pembaruan yang valid sampai channel atau metadata bundle diatur ulang.

Untuk tester ini, masukkan baseline native yang perangkat mengirimkan sebagai version_build, kemudian bandingkan dengan versi bundle remote yang ingin Capgo kirimkan.

Mengapa Capgo menggunakan Versi Semantik

Versi Semantik adalah standar versi yang paling banyak digunakan dalam pengembangan perangkat lunak. Dengan menggunakan semver, Capgo memastikan konsistensi dan keamanan ketika mengirimkan pembaruan live ke aplikasi-aplikasi Capacitor Anda.

Standar semver memungkinkan Capgo untuk memahami secara tepat apa saja perubahan yang terkandung dalam setiap pembaruan:

  • Pembaruan patch (1.0.0 → 1.0.1): Perbaikan bug, aman untuk diterapkan secara otomatis
  • Pembaruan minor (1.0.0 → 1.1.0): Fitur baru, kompatibel mundur
  • Pembaruan mayor (1.0.0 → 2.0.0): Perubahan yang mengganggu, memerlukan rilis aplikasi native di toko aplikasi

Hal ini mencegah Capgo untuk pernah mengirimkan pembaruan yang tidak kompatibel ke native code Anda, melindungi pengguna Anda dari crash 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 pra-rilis dan metadata pembangunan:

🏷️ Metadata Pembangunan (+) - Layer "Cosmetik"

1.2.0+20240315.142530
Waktu stempel untuk pelacakan pengiriman
1.2.0+refresh.ui.tema.gelap
Deskripsi perbarui UI untuk tim desain
1.2.0+build.4729.commit.a1b2c3d
Nomor pembangunan CI/CD dan komit git

Penting: Metadata pembangunan diabaikan dalam keutuhan versi - 1.2.0+anything sama 1.2.0 untuk logika pembaruan Capgo.

🔧 Identifikator Pra-Rilis (-) - Saluran Pengembangan

1.3.0-beta.1
Saluran Pengujian Beta
1.3.0-hotfix.payment
Cabang Perbaikan Darurat
1.3.0-feature.newapi
Cabang 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

Penggunaan Semver Nyata & Strategi Tim

🚀 Pengembangan Startup / Cepat

0.1.0 - Rilis MVP pertama
0.2.0-beta.1 - Pengujian fitur baru
0.2.0+ui.v2 - Metadata merancang ulang UI
1.0.0 - Rilis siap produksi

Gunakan 0.x.x untuk pengembangan pre-1.0, metadata untuk tracking desain

🏢 Perusahaan / Terregulasi

2.1.0 → Rilis kuartal
2.1.1+sec.patch.cve2024 → Patch keamanan dengan tracking
2.2.0-rc.1+audit.ready → Kandidat rilis audit sebelumnya

Semantik Versi 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 Asset

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 Tanggal

Pre-release untuk Pengujian, Metadata untuk Mengikuti Pelacakan Pengembangan

🌍 Strategi Multi-Platform

1.3.0+ios.optimized → Optimasi iOS khusus
1.3.0+android.material3 → Perbaruan desain Android
1.3.0+web.pwa.ready → Kemampuan PWA

Sama versi, metadata platform khusus

🔄 Integrasi CI/CD

1.4.0-alpha.1+build.123 → Pengiriman otomatis sebelum rilis
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 update yang berbeda
  • Gabungkan kedua-duanya untuk fleksibilitas maksimum: 1.2.0-beta.1+ui.dark.theme.20240315
  • Ingatlah: Capgo menghormati aturan semver sebelumnya, jadi rencanakan strategi saluran Anda sesuai dengan itu

Penting: Capgo menggunakan semver semantik yang ketat

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

Misalnya, npm menganggap versi seperti 1.0.0-alpha.1 berbeda dengan yang diperlukan oleh spesifikasi. Lihat masalah yang dilaporkan kami dan usaha untuk memperbaiki yang tidak pernah digabungkan. Versi Semantik yang Valid

✓ Rilis standar

1.0.0 ✓
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

__CAPGO_KEEP_0__ Perilaku Perbarui

v1.0.0 Versi Semantik Tidak Valid
1.0 ✗ Tidak Diperbolehkan 'v' di Awal
1.0.0.0 ✗ Tidak Ada Versi Patch
1.0.0- ✗ Terlalu Banyak Bagian Versi
1.0.0+ ✗ Rilis Pra Kosong

Capgo Update Behavior

✓ Strategi Minor Mengizinkan Perubahan Patch di Garis Sama Major.Minor, Misalnya 1.0.0 -> 1.0.1
✓ Strategi patch blok 1.0.0 -> 1.0.1. Hanya memungkinkan perubahan sufiks seperti 1.0.0-beta.1 -> 1.0.0-beta.2.
✗ Strategi mayor blok target bundle dengan mayor yang lebih tinggi dari basis native, misalnya 1.0.0 -> 2.0.0
⚠ Pengaman penurunan menggunakan keutamaan semver penuh, sehingga stabil 1.0.0 lebih baru dari 1.0.0-beta.2

Alat ini mengikuti spesifikasi Versi Semantik resmi berbeda dengan implementasi __CAPGO_KEEP_0__ unlike npm's implementation.