Reactivecocoa: Pertanyaan: Tanggal rilis

Proyek ini sepenuhnya didorong oleh sukarelawan, jadi tidak mungkin untuk mengatakannya. Saya tidak berpikir saya bahkan bisa mendapatkan keuntungan.

Tetapi karena RAC 4.2.2 kompatibel dengan Swift 2.3, Anda dapat menggunakannya dengan Xcode 8 dan tidak boleh diblokir dari pengiriman aplikasi Anda. (Anda mungkin diblokir untuk pindah ke Swift 3, tapi itu hanya ketidaknyamanan.) Jika Anda _harus_ menggunakan Swift 3, maka Anda mungkin dapat menggunakan RAC dan repo terkait seperti yang ada di cabang master mereka hari ini. Namun perlu diketahui bahwa mungkin akan ada beberapa perubahan yang melanggar.

OK mengerti.

Saya siap membantu dan menjadi sukarelawan, jika itu akan mempercepat proyek.

Saya dapat membantu dengan banyak hal. Tolong, tulis saya di email jika Anda memutuskan untuk menerima bantuan saya. Saya akan berbagi dengan Anda lebih banyak informasi tentang diri saya melalui email.

Ya, saya berada di kapal yang sama dengan beberapa aplikasi pengiriman yang menggunakan RAC/dll. tetapi saya telah berhasil menarik ReactiveSwift, ReactiveCocoa, dll. sebagai dependensi pada cabang pengembangan saya sendiri. Dibutuhkan beberapa upaya untuk tetap di atas hal-hal saat mereka bergerak cepat, tetapi saya merekomendasikan tip berikut untuk menjaga diri Anda agar tidak menjadi gila (dengan asumsi Anda menggunakan Carthage):

Langkah 0: pindahkan kode Anda ke Xcode 8 menggunakan Swift 2.3 dan versi rilis terbaru dari dependensi Anda

Ini akan membuat Anda tidak perlu menggali Xcode 7.x setiap kali Anda harus mengirimkan pemeliharaan atau pembaruan lainnya sementara itu sebelum port Swift 3 Anda siap. Ini juga akan membuat port Swift 3 sedikit lebih mudah, karena Anda akan memiliki beberapa peringatan penghentian Swift yang dapat Anda tangani selagi masih mudah diperbaiki.

Langkah 1: Tambahkan dependensi baru yang mendukung Swift 3

Arahkan ke cabang master (atau lainnya) dari dependensi Anda di Cartfile Anda, dan pastikan carthage membangun semuanya dengan baik saat Anda menjalankan carthage update . Ini mungkin tidak segera bekerja, dan Anda dapat menghabiskan banyak waktu "bermain detektif" untuk menemukan cabang yang sesuai.

Yang mengatakan, saya akan terkejut jika Anda masih memiliki beberapa repo yang tidak memiliki dukungan Swift 3 yang mudah ditemukan di cabang atau garpu.

Langkah 2: Sematkan dependensi ini pada revisi tertentu, dan bukan master

Setelah Anda memiliki seperangkat dependensi, salin revisi dari Cartfile.resolved ke Cartfile.private dan Cartfile sebagaimana mestinya. Jangan tentukan master atau penentu cabang lainnya di Cartfile Anda, karena ini akan menjadi sumber banyak kesedihan.

Mengapa menyematkan dependensi? Nah, jika Anda seperti saya dan Anda juga memiliki perpustakaan ketergantungan Anda sendiri yang sedang porting, maka Anda akan menemukan bahwa carthage update akan menempatkan Anda ke dalam lingkaran yang tampaknya tak berujung untuk berulang kali melanggar kode Anda saat pengembangan sedang berlangsung.

Catatan: Anda harus _juga_ menyematkan revisi ketergantungan tersebut untuk RAC/etc dalam kerangka kerja pribadi Anda selama pengembangan, dan jika Anda memiliki kerangka kerja pribadi Anda sendiri, Anda harus memulai dengan Langkah 1 dalam kerangka kerja tersebut…

Langkah 3: Port kode Anda ke Swift 3

Semoga berhasil! Ini tidak akan semudah yang Anda harapkan, dan Reactive{Cocoa,Swift} memiliki banyak perubahan API mereka sendiri yang akan membutuhkan waktu dan pemikiran untuk diintegrasikan.

Langkah 4: Pindahkan spesifikasi Cartfile dari revisi yang disematkan kembali ke master

Jalankan kembali perintah carthage update , lalu kembali dan ulangi Langkah 2.

Langkah 5: (TBD - Setelah ReactiveCocoa semua dirilis) Kembalikan Cartfile untuk menunjuk pada rilis Swift 3

Pada titik ini Anda harus baik untuk bergerak maju. Bahkan dengan rilis alpha/etc, Anda mungkin harus tetap berpegang pada revisi yang disematkan untuk sementara waktu.

Juga? Benar-benar tidak ada yang menjamin bahwa "rilis resmi" akan menjadi sangat stabil (atau bahkan dapat digunakan dalam aplikasi spesifik Anda) untuk sementara waktu. Sejauh yang saya tahu, sebagian besar churn API telah dilakukan tanpa konsumsi API yang ekstensif dalam proyek-proyek besar.

Jadi, tidak ada yang salah dengan mengirimkan revisi master dalam aplikasi ukuran apa pun. Jika lulus semua pengujian Anda, dan tidak memiliki masalah kinerja yang nyata atau regresi lainnya, maka itu baik untuk pergi. Ini tidak seperti @mdiep atau pengelola lain yang menekan tombol "

Di atas adalah tempat bantuan Anda masuk. Gunakan API, uji pustaka dalam bentuknya saat ini, dan laporkan (atau lebih baik, perbaiki!) masalah yang Anda temui di aplikasi Anda.

Semoga ini membantu!

Terima kasih. Ya, ini akan banyak membantu. :)