Tautan ke konten utama

Capgo Tester Semver

Periksa kompatibilitas kebijakan saluran terhadap dasar native yang dikirim sebagai versi_build

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

Versi paket yang ditugaskan ke saluran yang diperbaiki.

Masukkan dua versi semantik untuk melihat perbandingan

Apa "Versi Dasar Native" berarti

Versi Dasar Native adalah versi aplikasi native yang dikirimkan ke Capgo sebagai version_build ketika perangkat meminta server pembaruan untuk sebuah paket. Dalam sebuah aplikasi Capacitor, nilai tersebut dapat berasal dari CapacitorUpdater.version di capacitor.config.*. If that setting is not present, the plugin falls back to the native app version from iOS or Android. Do not assume it is your package.json versi kecuali build Anda menyalin nilai tersebut ke konfigurasi atau metadata native.

Capgo masih menggunakan version_name Untuk mengetahui versi bundle yang diunduh saat ini. Pola semver saluran seperti major, minordan patch bandingkan paket remote terhadap version_build.

Capacitor konfigurasi

Setel CapacitorUpdater.version ketika Anda ingin satu versi spesifik dikirim oleh aplikasi.

Pro: Jika Anda ingin mengirimkan satu versi eksplisit melalui aplikasi.

Pro: Konfigurasi yang ketinggalan dapat melaporkan versi yang salah jika Anda lupa memperbarui sebelum rilis native.

Versi Aplikasi Native

Pilih versi platform, seperti iOS CFBundleShortVersionString atau Android versionName.

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

Kekurangan: mengubahnya memerlukan pembangunan native dan dapat berbeda antar platform jika pengaturan rilis bergeser.

Target Paket

Bandingkan dengan versi paket remote, aturan semver channel, atau konstrain unggah metadata seperti --min-update-versionSalah satu syarat yang harus dipenuhi adalah --disable-auto-update metadata.

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 metadata kanal atau 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 Semantik Versi

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

Standar semver 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): Fitur baru, kompatibel dengan versi sebelumnya
  • Perbaruan besar (1.0.0 → 2.0.0): Pembaharuan yang mengganggu, memerlukan rilis aplikasi native

Ini mencegah Capgo dari pernah mengirimkan pembaruan yang tidak kompatibel ke aplikasi code Anda, melindungi pengguna dari crash dan memastikan aplikasi 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 Kosmetik

1.2.0+20240315.142530
✍ Build Metadata (+) - Layer Kosmetik
Waktu timestamp untuk tracking peluncuran
Deskripsi update UI untuk tim desain
1.2.0+build.4729.commit.a1b2c3d
Nomor build CI/CD dan commit Git

Penting: Metadata build diabaikan dalam urutan versi - 1.2.0+anything setara 1.2.0 untuk logika update Capgo.

🔧 Identifikasi Prerelease (-) - Saluran Pengembangan

1.3.0-beta.1
Saluran pengujian beta
1.3.0-hotfix.payment
Saluran perbaikan darurat
1.3.0-fitur baru API
Uji coba cabang 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+metadata UI dan tanggal 20240315
Kandidat rilis dengan metadata UI dan tanggal

Contoh Penggunaan Semver Nyata & Strategi Tim

🚀 Pengembangan Awal / Pengembangan Cepat

0.1.0 - Rilis MVP pertama
0.2.0-beta.1 - Uji coba fitur baru
0.2.0+ui.v2 - Metadata perancangan 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 kuartal
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

🎮 Permainan / Aplikasi 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 Kritis Bug
1.2.1+urgent.20240315.1430 → Diterbitkan dengan Tanggal

Pre-release untuk pengujian, metadata untuk pelacakan pengiriman

🌍 Strategi Multi-Platform

1.3.0+ios.optimized → iOS-specific optimizations
1.3.0+android.material3 → Perbarui 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 → Perbaikan Otomatis Pre-release
1.4.0+deploy.staging.456 → Pengembangan Staging
1.4.0+prod.final.789 → Pengembangan Produksi

Versi otomatis dengan metadata pengembangan

💡 Tips Pro:
  • Pakai metadata pembangunan (+) untuk melacak, tanggal, atau informasi kosmetik yang tidak mempengaruhi konsistensi
  • Pakai identifikasi pra-rilis (-) untuk saluran pengembangan yang memerlukan prioritas pembaruan yang berbeda
  • Pakai kombinasi 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 resmi secara ketat. npm memiliki perbedaan 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 halaman kami masalah yang dilaporkan dan perbaikan yang pernah dicoba yang tidak pernah disatukan.

Versi Semantik yang Sah

1.0.0 ✓ Rilis Standar
2.1.3-alpha ✓ Rilis Pra-Rilis
1.0.0-beta.1 ✓ Rilis Pra-Rilis 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 patch versi
1.0.0.0 ✗ Terlalu banyak bagian versi
1.0.0- ✗ Kosong pre-release
1.0.0+ ✗ Kosong metadata build

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 bundle target dengan major lebih tinggi dari baseline native, misalnya 1.0.0 -> 2.0.0
⚠ Pelindungan penurunan menggunakan keutamaan semver penuh, sehingga stabil 1.0.0 lebih baru dari 1.0.0-beta.2

Ini alat mengikuti spesifikasi Versi Semantik resmi Tidak seperti implementasi __CAPGO_KEEP_0__ tidak seperti implementasi npm