Lompat ke konten utama
Capgo logo

Capgo Tester Semver

Periksa konseli kebijakan kompatibilitas 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 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 di capacitor.config.*. Jika pengaturan tersebut tidak package.json tersedia, plugin kembali ke versi aplikasi native dari iOS atau Android. Jangan asumsikan itu adalah versi Anda kecuali Anda memindahkan nilai tersebut ke konfigurasi atau metadata native.

Capgo masih menggunakan version_name untuk mengetahui bundle yang diunduh mana yang sedang terinstal. major, minorkebijakan semver channel seperti patch , dan version_build.

Capacitor config

__CAPGO_KEEP_0__ konfigurasi CapacitorUpdater.version Set

ketika Anda ingin satu versi eksplisit dikirim oleh aplikasi. Pro:

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

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

Versi aplikasi native CFBundleShortVersionString atau Android versionName.

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

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

Target Bundle

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

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

Con: aturan yang terlalu ketat dapat menghalangi update yang valid hingga channel atau metadata bundle diatur ulang.

Untuk tester ini, masukkan baseline native yang dikirimkan perangkat sebagai version_buildlalu bandingkan dengan bundle remote versi yang Anda inginkan Capgo untuk kirimkan.

Mengapa Capgo menggunakan Semantic Versioning

Semantic Versioning adalah standar versi yang paling luas diterima dalam pengembangan perangkat lunak. Dengan menggunakan semver, Capgo memastikan konsistensi dan keamanan ketika mengirimkan update live ke aplikasi Capacitor Anda.

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

  • 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 mundur
  • Pembaruan mayor (1.0.0 → 2.0.0): Pembaruan yang mengganggu, memerlukan rilis aplikasi native di toko

Ini mencegah Capgo untuk pernah mengirimkan update yang tidak kompatibel ke aplikasi native code Anda, melindungi pengguna 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 penanda pra-rilis dan metadata bangunan:

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

1.2.0+20240315.142530
Waktu stempel untuk pelacakan pengiriman
1.2.0+ui.refresh.dark-mode
Deskripsi perbarui UI untuk tim desain
1.2.0+build.4729.commit.a1b2c3d
Nomor bangunan CI/CD dan commit Git

Penting: Metadata pembangunan diabaikan dalam urutan keutamaan versi - 1.2.0+anything sama 1.2.0 untuk Capgo's logika pembaruan.

🔧 Identifikasi Pra-Rilis (-) - Saluran Pengembangan

1.3.0-beta.1
Saluran uji coba beta
1.3.0-hotfix.payment
Cabang perbaikan darurat
1.3.0-feature.newapi
Cabang uji coba fitur

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

Pendekatan Hibrid - Terbaik dari Dunia

1.3.0-rc.1+ui.redesign.20240315
Kandidat Rilis dengan Metadata UI dan Tanggal

Penggunaan Semver yang 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 UI redesign
1.0.0 - Rilis siap produksi

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

🏢 Perusahaan / Regulasi

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

Strict semver 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 tracking konten

⚡ Strategi Hotfix

1.2.0 → Produksi saat ini
1.2.1-hotfix.payment → Perbaikan bug kritikal
1.2.1+urgent.20240315.1430 → Dirilis dengan timestamp

Versi pra-rilis untuk pengujian, metadata untuk pemantauan peluncuran

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

Versi yang sama, metadata platform khusus

Integrasi CI/CD 🔄

1.4.0-alpha.1+build.123 → Rilis pra pra-rilis otomatis
1.4.0+deploy.staging.456 → Pengembangan tahap pengujian
1.4.0+prod.final.789 → Pengembangan tahap produksi

Pengaturan versi otomatis dengan metadata peluncuran

Tips Pro: 💡
  • Gunakan metadata pembangunan (+) untuk tracking, tanggal, atau informasi kosmetik yang tidak mempengaruhi konsistensi
  • Gunakan identifikasi pre-release (-) untuk saluran pengembangan yang memerlukan prioritas pembaruan yang berbeda
  • Gabungkan keduanya untuk fleksibilitas maksimum: 1.2.0-beta.1+ui.dark.theme.20240315
  • Pertimbangkan: Capgo menghormati aturan semver prioritas, jadi rencanakan strategi saluran Anda sesuai

Penting: Capgo menggunakan semver yang ketat

Berbeda dengan implementasi semver npm, Capgo mengikuti spesifikasi SemVer secara ketat. npm's node-semver 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 laporkan dan upaya perbaikan yang tidak pernah digabungkan.

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 Diperbolehkan
1.0 ✗ Tidak Ada Versi Patch
1.0.0.0 ✗ Terlalu Banyak Bagian Versi
1.0.0- ✗ Pra-Rilis Kosong
1.0.0+ ✗ Metadata Pembangunan Kosong

Capgo Perbarui Sifat

✓ Strategi Minor memungkinkan perubahan patch di garis yang 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 Mayor memblokir bundle target dengan major yang lebih tinggi dari baseline native, misalnya 1.0.0 -> 2.0.0
⚠ Pengaman Penurunan menggunakan keutamaan semver yang lengkap, sehingga stabil 1.0.0 lebih baru dari 1.0.0-beta.2

Alat ini mengikuti spesifikasi Pengaturan Versi Semantis resmi berbeda dengan implementasi npm.