Langsung ke konten utama

Semver Tester Capgo

Periksa kompatibilitas kebijakan channel terhadap baseline native yang dikirim sebagai version_build

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

Versi bundle yang ditetapkan untuk channel yang di-resolve.

Masukkan dua versi semantik untuk melihat perbandingan

Apa arti "Native Baseline Version"

Native Baseline Version adalah versi aplikasi native yang dikirim ke Capgo sebagai version_build saat perangkat meminta bundle ke server update. Di aplikasi Capacitor, nilai itu bisa berasal dari CapacitorUpdater.version di capacitor.config.*. Jika pengaturan tersebut tidak ada, plugin akan fallback ke versi aplikasi native dari iOS atau Android. Jangan asumsikan itu adalah versi package.json Anda, kecuali build Anda menyalin nilai tersebut ke config atau metadata native.

Capgo tetap menggunakan version_name untuk mengetahui bundle mana yang sedang terpasang. Kebijakan semver channel seperti major, minor, dan patch membandingkan bundle remote dengan version_build.

config Capacitor

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

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

Kontra: config yang usang dapat melaporkan versi yang salah jika Anda lupa memperbaruinya sebelum rilis native.

Versi aplikasi native

Gunakan versi platform, seperti iOS CFBundleShortVersionString atau Android versionName.

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

Kontra: mengubahnya memerlukan native build dan bisa berbeda antar platform jika pengaturan release berubah.

Targeting bundle

Bandingkan dengan versi bundle remote, aturan semver channel, atau batasan upload metadata seperti --min-update-version. Channel harus menggunakan --disable-auto-update metadata.

Pro: mencegah pengiriman JavaScript yang membutuhkan native code lebih baru ke biner aplikasi lama.

Kontra: aturan yang terlalu ketat bisa memblokir update valid sampai metadata channel atau bundle disesuaikan.

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

Mengapa Capgo menggunakan Semantic Versioning

Semantic Versioning adalah standar versioning yang paling banyak digunakan dalam pengembangan software. Dengan semver, Capgo menjamin kompatibilitas dan keamanan saat mengirimkan live updates ke aplikasi Capacitor Anda.

Standar semver memungkinkan Capgo memahami dengan tepat perubahan apa saja yang disertakan dalam setiap update:

  • Update patch (1.0.0 → 1.0.1): Perbaikan bug, aman diterapkan otomatis
  • Pembaruan minor (1.0.0 → 1.1.0): Fitur baru, tetap backward compatible
  • Pembaruan major (1.0.0 → 2.0.0): Breaking changes, perlu rilis ke app store native

Ini mencegah Capgo mengirimkan update yang tidak kompatibel ke code native Anda, sehingga melindungi pengguna dari crash dan menjaga aplikasi tetap stabil.

Strategi Semver yang Fleksibel: Lebih dari Versioning Dasar

Meski semver sangat ketat pada format intinya, Anda bisa memperluasnya sesuai kebutuhan tim menggunakan identifikasi pre-release dan metadata build:

🏷️ Metadata Build (+) - Lapisan "Kosmetik"

1.2.0+20240315.142530
Timestamp untuk pelacakan deployment
1.2.0+ui.refresh.dark-mode
Deskripsi pembaruan UI untuk tim desain
1.2.0+build.4729.commit.a1b2c3d
Nomor build CI/CD dan git commit

Penting: Metadata build diabaikan dalam prioritas versi - 1.2.0+anything sama dengan 1.2.0 untuk logika pembaruan Capgo.

🔧 Identifier Pre-release (-) - Channel Pengembangan

1.3.0-beta.1
Channel pengujian beta
1.3.0-hotfix.payment
Branch perbaikan mendesak
1.3.0-feature.newapi
Pengujian branch fitur

Catatan: Versi pre-release memiliki prioritas lebih rendah - 1.3.0-beta.1 < 1.3.0

🎯 Pendekatan Hibrida - Terbaik dari Keduanya

1.3.0-rc.1+ui.redesign.20240315
Release candidate dengan metadata UI dan timestamp

Kasus Penggunaan Semver & Strategi Tim di Dunia Nyata

🚀 Startup / Pengembangan Cepat

0.1.0 - Rilis MVP pertama
0.2.0-beta.1 - Testing fitur baru
0.2.0+ui.v2 - Metadata redesign UI
1.0.0 - Siap production

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

🏢 Enterprise / Teregulasi

2.1.0 → Rilis kuartalan
2.1.1+sec.patch.cve2024 → Security patch dengan tracking
2.2.0-rc.1+audit.ready → Release candidate pra-audit

Semver ketat dengan metadata kepatuhan

🎮 Aplikasi Gaming / Kreatif

1.0.0+season.winter.2024 → Konten musiman
1.1.0+event.halloween → Fitur berbasis event
1.2.0+assets.hd.remaster → Update aset

Metadata kreatif untuk tracking konten

⚡ Strategi Hotfix

1.2.0 → Production saat ini
1.2.1-hotfix.payment → Perbaikan bug kritis
1.2.1+urgent.20240315.1430 → Rilis dengan timestamp

Pre-release untuk testing, metadata untuk tracking deployment

🌍 Strategi Multi-Platform

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

Versi sama, metadata spesifik platform

🔄 Integrasi CI/CD

1.4.0-alpha.1+build.123 → Pre-release otomatis
1.4.0+deploy.staging.456 → Deployment staging
1.4.0+prod.final.789 → Deployment produksi

Versioning otomatis dengan metadata deployment

💡 Tips Pro:
  • Gunakan build metadata (+) untuk pelacakan, timestamp, atau info kosmetik yang tidak memengaruhi kompatibilitas
  • Gunakan pre-release identifiers (-) untuk channel development yang membutuhkan prioritas update berbeda
  • Gabungkan keduanya untuk fleksibilitas maksimal: 1.2.0-beta.1+ui.dark.theme.20240315
  • Ingat: Capgo mematuhi aturan prioritas semver, jadi rencanakan strategi channel Anda dengan tepat

Penting: Capgo menggunakan semantic versioning yang ketat

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

Sebagai contoh, npm memperlakukan versi seperti 1.0.0-alpha.1 berbeda dari yang dipersyaratkan spesifikasi. Lihat issue yang dilaporkan dan upaya perbaikan yang tidak pernah di-merge.

Versi Semantik yang Valid

1.0.0 ✓ Rilis standar
2.1.3-alpha ✓ Pre-release
1.0.0-beta.1 ✓ Pre-release dengan nomor
1.0.0+build.1 ✓ Metadata build
1.0.0-rc.1+build.1 ✓ Versi lengkap

Versi semantik tidak valid

v1.0.0 ✗ Awalan 'v' tidak diizinkan
1.0 ✗ Versi patch hilang
1.0.0.0 ✗ Terlalu banyak bagian versi
1.0.0- ✗ Pre-release kosong
1.0.0+ ✗ Metadata build kosong

Perilaku Update Capgo

✓ Strategi minor mengizinkan perubahan patch dalam baris major.minor yang sama, misalnya 1.0.0 -> 1.0.1
✓ Strategi patch memblokir 1.0.0 -> 1.0.1. Hanya mengizinkan perubahan sufiks seperti 1.0.0-beta.1 -> 1.0.0-beta.2.
✗ Strategi Major memblokir bundle target dengan versi major lebih tinggi daripada baseline native, misalnya 1.0.0 -> 2.0.0
⚠ Proteksi downgrade memakai urutan prioritas semver penuh, jadi versi stabil 1.0.0 lebih baru daripada 1.0.0-beta.2

This tool follows the official spesifikasi resmi Semantic Versioning berbeda dengan implementasi npm.