Lompat ke konten utama
Tutorial

Cara merilis versi utama di capgo

Pahami bagaimana dan kapan perlu merilis versi utama untuk aplikasi Anda tanpa mengganggu aplikasi pengguna Anda

Martin Donadieu

Martin Donadieu

Spesialis Konten

Cara merilis versi utama di capgo

Ketika merilis versi utama

Versiing adalah sulit untuk dikelola, biasanya Anda ingin mengirimkan pembaruan utama ketika ada perubahan besar yang terjadi untuk pengguna.

Tapi versiing tidak dibuat untuk itu, versi aplikasi toko adalah berbeda dari versi Native.

Versi Native dibuat untuk mengelola perubahan yang mengganggu di dalamnya. code

Di IOS, misalnya, iOS 16 adalah store version dari Apple, tetapi versi code adalah 20A5283p (mereka tidak tampaknya menggunakan SemVer di sana)

Sekarang sudah jelas kita tidak mencampur aduknya dan menggunakan sesuai dengan tujuan mereka!

Pelepasan Besar

Di aplikasi Capacitor Anda, pelepasan besar diperlukan ketika terjadi perubahan yang memecah. Misalnya, target IOS baru (15 ke 16), atau versi Capacitor baru (3 ke 4), atau plugin (1.2 ke 2.0) yang Anda gunakan telah diperbarui ke versi besar.

Perubahan ini berarti semua alat harus disesuaikan untuk menangani perubahan yang memecah.

Itulah mengapa Capgo mengikuti sistem ini. Jadi jika Anda melepaskan versi besar, Capgo tidak akan mengirimkannya ke pengguna yang tidak memiliki instalasi dari toko.
Sikap ini dapat disesuaikan. Anda dapat mengetahui lebih lanjut tentang hal ini di sini

Versi-Versi

Di mana Capgo mencari versi untuk dibandingkan

IOS

Akan digunakan oleh Capgo untuk membandingkan dengan versi JavaScript dan menemukan Perubahan Mayor

Di IOS variabel ini ditetapkan pada project Anda di sini ios/App/App/Info.plist di bawah kunciCFBundleShortVersionString atau ios/App/App.xcodeproj/project.pbxproj di bawah kunci MARKETING_VERSION jika MARKETING_VERSION telah ditetapkan di file Info.plist Anda

Anda dapat mengatasi perilaku ini dengan menetapkan kunci versi di capacitor.config.json file Dokumen di sini

Android

Akan digunakan oleh Capgo untuk membandingkan dengan versi JavaScript dan menemukan Perubahan Besar

di Android, variabel ini ditetapkan pada proyek Anda di sini android/app/build.gradle di bawah kunci defaultConfig.versionName

Anda dapat mengatasi perilaku ini dengan menetapkan kunci versi di capacitor.config.json file Dokumen di sini

JavaScript

Akan digunakan oleh Capgo untuk membandingkan dengan versi Native dan menemukan Perubahan Besar

di JavaScript, variabel ini ditetapkan pada proyek Anda di sini package.json di bawah kunci version

Contoh

Aplikasi Ionic Anda saat ini dirilis dengan versi 1.2.3 dengan Capacitor 3

Anda melakukan upgrade ke capacitor 4.

Anda perlu meningkatkan nomor versi Anda ke 2.2.3, kemudian semua paket Anda termasuk Capgo dengan peringatan perubahan besar ini.

Ketika Anda merilis versi ini ke Capgo dan App Store.

Semua pembaruan hidup berikutnya di Capgo 2.2.4 tidak akan dikirimkan kepada pengguna dengan 1.2.3 versi. Hanya dengan 2.2.3 versi.

Jika Anda mengikuti pola ini, tidak perlu khawatir lagi, semua sudah diatur dengan baik.

Jika saya tidak mengikuti instruksi ini

Dalam hal ini, itu berarti Anda harus mengirimkan aplikasi baru Anda dengan Capacitor 4 ke Apple dan Google, tetapi jangan ke Capgo.

Kemudian Anda harus menunggu 100% pengguna Anda, memiliki aplikasi atau setidaknya 90%, itu akan memakan waktu bulan-bulan, mungkin.

Sementara waktu ini Anda tidak dapat mengirimkan perbaruan apa pun dengan Capgo, karena pengguna lama tidak dapat mendapatkan versi baru.

Pembaruan waktu nyata untuk aplikasi Capacitor

Ketika bug layer web masih aktif, kirimkan perbaikan melalui Capgo daripada menunggu hari-hari untuk persetujuan toko aplikasi. Pengguna mendapatkan pembaruan di latar belakang sementara perubahan native tetap berada di jalur review normal.

Mulai Sekarang

Terbaru dari Blog Kami

Capgo memberikan Anda wawasan terbaik yang Anda butuhkan untuk membuat aplikasi mobile profesional yang sebenarnya.