Capgo Semver Tester

Periksa kompatibilitas kebijakan saluran terhadap dasar native yang dikirim sebagai versi_build

Versi Dasar Native

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

Versi Jarak Jauh

Versi bundle yang diberikan kepada saluran yang diperiksa.

Masukkan dua versi semantik untuk melihat perbandingan

Apa itu "Versi Dasar Native"

Versi Dasar Native adalah versi aplikasi native yang dikirim ke Capgo sebagai version_build ketika perangkat meminta server pembaruan untuk bundle. Dalam aplikasi Capacitor, nilai tersebut dapat berasal dari CapacitorUpdater.version dalam capacitor.config.*. Jika pengaturan tersebut tidak ada maka plugin akan kembali ke versi aplikasi asli dari iOS atau Android. Jangan asumsikan itu adalah versi Anda kecuali Anda membuat build yang menyalin nilai tersebut ke konfigurasi atau metadata asli. package.json __CAPGO_KEEP_0__ masih menggunakan

Capgo still uses version_name to know which downloaded bundle is currently installed. Channel semver policies such as major, minor, dan patch menggunakan kebijakan untuk membandingkan bundle remote terhadap version_build.

Capacitor konfigurasi

Set CapacitorUpdater.version ketika Anda ingin mengirimkan satu versi spesifik yang dikirimkan oleh aplikasi.

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

Kontra: Konfigurasi yang tidak diperbarui dapat melaporkan versi yang salah jika Anda lupa memperbaruhinya sebelum rilis native.

Versi aplikasi native

Gunakan versi platform, seperti iOS CFBundleShortVersionString atau Android versionName.

Kelebihan: Sesuai dengan versi biner yang diinstal oleh pengguna dari TestFlight, App Store, Play Store, atau pengujian internal.

Kontra: Mengubahnya memerlukan pembangunan native dan dapat berbeda antar platform jika pengaturan rilis bergeser.

Target bundel

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

Kelebihan: mencegah pengiriman JavaScript yang memerlukan native code yang lebih baru ke biner aplikasi lama.

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

Untuk tester ini, masukkan dasar native yang perangkat mengirimkan sebagai version_buildlalu bandingkan dengan versi paket remote yang ingin Capgo kirimkan.

Mengapa Capgo menggunakan Semantic Versioning

Penggunaan 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 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): Pembaruan bug, aman untuk diterapkan secara otomatis
Pembaruan minor (1.0.0 → 1.1.0): Fitur-fitur baru, kompatibel mundur
Perubahan besar (1.0.0 → 2.0.0): Perubahan yang mengganggu, memerlukan rilis aplikasi native di toko aplikasi

Ini mencegah Capgo dari pernah mengirimkan pembaruan yang tidak kompatibel ke code native Anda, melindungi pengguna Anda dari crash dan memastikan aplikasi Anda tetap stabil.

Strategi Semver Fleksibel: Lebih dari Pengaturan 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 'Cosmetic'

1.2.0+20240315.142530

Timestamp untuk pelacakan pengiriman

1.2.0+ui.refresh.dark-mode

Deskripsi perbaruan UI untuk tim desain

1.2.0+build.4729.commit.a1b2c3d

Nomor perbaruan CI/CD dan commit Git

Perlu diingat: Metadata perbaruan diabaikan dalam urutan keutamaan versi - 1.2.0+anything sama dengan 1.2.0 untuk Capgo's logika perbaruan.

🔧 Identifikasi Prerelease (-) - Saluran Pengembangan

1.3.0-beta.1

Saluran pengujian beta

1.3.0-hotfix.payment

Cabang perbaruan darurat

1.3.0-fitur.baruapi

Cabang fitur pengujian

Perlu diingat: Versi pra-rilis memiliki prioritas yang lebih rendah - 1.3.0-beta.1 < 1.3.0

🎯 Pendekatan Hibrida - Terbaik dari Kedua Dunia

1.3.0-kandidat.rilis.1+ui.redesign.20240315

Kandidat rilis dengan metadata UI dan tanggal

Penggunaan Semver Nyata & Strategi Tim

🚀 Pengembangan Awal / Pengembangan 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 untuk produksi

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

🏢 Perusahaan / Regulasi

2.1.0 → Rilis kuartalan

2.1.1+sec.patch.cve2024 → Patch keamanan dengan tracking

2.2.0-rc.1+audit.ready → Kandidat rilis pra-audit

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 pengawasan konten

⚡ Strategi Perbaikan Hotfix

1.2.0 → Produksi saat ini

1.2.1-hotfix.payment → Perbaikan bug kritikal

1.2.1+urgent.20240315.1430 → Diterbitkan dengan timestamp

Pre-release untuk pengujian, metadata untuk pelacakan penggunaan

🌍 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

Versi yang sama, metadata spesifik platform

🔄 Integrasi CI/CD

1.4.0-alpha.1+build.123 → Pre-release otomatis

1.4.0+deploy.staging.456 → Pengembangan Staging

1.4.0+prod.final.789 → Pengembangan Produksi

Versi Otomatis dengan Metadata Pengembangan

💡 Tips Pro:

Gunakan metadata pembangunan (+) untuk melacak, tanggal, atau informasi kosmetik yang tidak mempengaruhi konsistensi
Gunakan identifikasi pra-rilis (-) untuk saluran pengembangan yang memerlukan prioritas pembaruan yang berbeda
Gabungkan kedua-duanya untuk fleksibilitas maksimum: 1.2.0-beta.1+ui.dark.theme.20240315
Ingatlah: Capgo menghormati aturan semver prioritas, jadi rencanakan strategi saluran Anda sesuai

Penting: Capgo menggunakan versi semantik yang ketat

Berbeda dengan implementasi semver npm, Capgo mengikuti spesifikasi SemVer resmi secara ketat. npm's node-semver 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 di masalah yang dilaporkan dan perbaikan yang dicoba yang tidak pernah diverifikasi.

Versi Semantik yang Valid

1.0.0 ✓ Rilis Standar

2.1.3-alpha ✓ Rilis Pra-Verifikasi

1.0.0-beta.1 ✓ Rilis Pra-Verifikasi dengan Nomor

1.0.0+build.1 ✓ Metadata Pembangunan

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

Versi Semantik yang Tidak Valid

v1.0.0 ✗ 'v' di awal tidak diizinkan

1.0 ✗ Tidak ada patch versi

1.0.0.0 ✗ Terlalu banyak bagian versi

1.0.0- ✗ Prerelease kosong

1.0.0+ ✗ Metadata build kosong

Capgo Perilaku Update

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

✓ Strategi patch menghalangi 1.0.0 -> 1.0.1. Hanya memungkinkan perubahan sufiks seperti 1.0.0-beta.1 -> 1.0.0-beta.2.

✗ Strategi major menghalangi bundle target dengan major yang lebih tinggi dari baseline 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 Pengaturan Versi Semantis berbeda dengan implementasi npm.