Saat merilis versi major
Versioning bisa sulit dikelola, biasanya Anda ingin mengirim update Major saat ada perubahan besar bagi pengguna.
Namun penomoran versi tidak dirancang untuk itu, versi App Store berbeda dengan versi Native.
Native version dibuat untuk mengelola breaking change pada code
Di iOS, misalnya, iOS 16 adalah store version dari Apple, tapi versi code adalah 20A5283p (mereka sepertinya tidak menggunakan SemVer di sana)
Sekarang jelas kita tidak mencampurnya dan menggunakannya sesuai fungsinya!
Rilis major
Di aplikasi Capacitor Anda, rilis major diperlukan saat terjadi breaking change. Contohnya, target iOS baru (15 ke 16), atau versi baru Capacitor (3 ke 4), atau plugin (1.2 ke 2.0) yang Anda gunakan telah diperbarui ke versi major.
Perubahan ini berarti semua tooling harus disesuaikan untuk menangani breaking change tersebut.
Itulah alasan Capgo mengikuti sistem ini.
Jadi jika Anda merilis versi major, Capgo tidak akan mengirimkannya ke user yang belum menginstalnya dari store.
Perilaku ini dapat dikustomisasi. Pelajari lebih lanjut di sini di sini
Versi
Di mana Capgo menemukan versi untuk dibandingkan
iOS
Akan digunakan oleh Capgo untuk membandingkan dengan versi JavaScript dan menemukan upgrade Major
Di iOS, variabel ini diatur pada proyek Anda di sini ios/App/App/Info.plist di bawah keyCFBundleShortVersionString atau ios/App/App.xcodeproj/project.pbxproj di bawah key MARKETING_VERSION jika MARKETING_VERSION sudah diatur di Info.plist Anda.
Anda bisa override perilaku ini dengan mengatur version key di
capacitor.config.jsonfile docs di sini
Android
Akan digunakan oleh Capgo untuk membandingkan dengan versi JavaScript dan menemukan major upgrade
di Android, variabel diatur pada proyek Anda di sini android/app/build.gradle di bawah key defaultConfig.versionName
Anda bisa override perilaku ini dengan mengatur version key di
capacitor.config.jsonfile docs di sini
JavaScript
Akan digunakan oleh Capgo untuk membandingkan dengan versi Native dan menemukan upgrade Major
di JavaScript, variabel var diatur pada proyek Anda di sini package.json di bawah key version
Contoh
Aplikasi Ionic Anda saat ini dirilis dengan versi 1.2.3 dengan Capacitor 3
Anda sedang melakukan upgrade ke capacitor 4.
Anda perlu memperbarui nomor versi Anda menjadi 2.2.3, lalu semua package Anda menyertakan Capgo untuk menandai perubahan besar ini.
Saat Anda merilis versi ini ke Capgo dan App Store.
Semua live update berikutnya di Capgo 2.2.4 tidak akan pernah dikirim ke user dengan 1.2.3 versi. Hanya dengan 2.2.3 versi.
Jika Anda mengikuti pola ini, tidak perlu khawatir, semuanya sudah tertangani dengan baik.
Jika saya tidak mengikuti ini
Dalam hal ini, artinya Anda harus mengirim aplikasi baru dengan Capacitor 4 ke Apple dan Google, tetapi tidak ke Capgo.
Lalu Anda harus menunggu sampai 100% pengguna Anda memiliki aplikasi itu, atau setidaknya 90%, yang kemungkinan memakan waktu berbulan-bulan.
Sementara itu, Anda tidak bisa mengirim update apa pun dengan Capgo, karena pengguna lama tidak bisa mendapatkan versi baru. Anda tidak punya cara untuk memilih hanya sebagian pengguna yang menerima update.
Lanjutkan dari Cara merilis versi major di capgo
Jika Anda menggunakan Cara rilis versi mayor di capgo untuk merencanakan rollback dan version control, hubungkan dengan Rollback untuk detail implementasi di Rollbacks, Targeting Versi untuk detail implementasi di Version Targeting, Perilaku Update untuk detail implementasi di Update Behavior, bundle untuk detail implementasi di bundle, dan Capgo Live Updates untuk workflow produk di Capgo Live Updates.
