PHP 8.6.0 RC3 Rilis 8 Oktober 2026: Waktunya Uji Source Code Kamu Sebelum Versi Final

PHP 8.6.0 RC3 (Release Candidate 3) resmi dirilis tim PHP pada 8 Oktober 2026. Ini adalah build uji publik menuju PHP 8.6 versi final yang dijadwalkan meluncur 19 November 2026. Kalau kamu menjual atau memakai source code berbasis Laravel, inilah momen terbaik untuk menguji kompatibilitas — bukan setelah versi finalnya keluar dan pembeli mulai komplain.

Artikel ini merangkum kabar rilisnya, jadwal lengkap menuju versi final, dan checklist praktis menguji source code kamu di RC3 sebelum terlambat. Detail fitur-fitur baru PHP 8.6 sudah kami bahas terpisah di artikel panduan PHP 8.6 — fokus artikel ini adalah kabar rilisnya dan apa yang harus kamu lakukan sekarang.

Apa itu PHP 8.6.0 RC3?

RC (Release Candidate) adalah tahap akhir sebelum versi final: semua fitur sudah "dibekukan" sejak fase beta, dan yang berubah di fase RC hanyalah perbaikan bug serta stabilitas. Pengumuman resmi di php.net berbunyi kurang lebih: "The PHP team is pleased to announce the first release candidate of PHP 8.6.0, RC3" — disertai peringatan tegas: jangan pakai versi ini di production, ini versi uji awal.

Satu fakta menarik dari siklus kali ini: RC1 dilewati karena kesalahan packaging, sehingga RC2 menjadi kandidat pertama yang bisa diuji publik. Artinya RC3 adalah build ketiga yang layak diuji — dan menurut jadwal, RC4 berikutnya dijadwalkan rilis 22 Oktober 2026.

Perlu diingat, detail perilaku di versi RC masih bisa berubah sampai versi final. Praktisi PHP Doğan Uçar yang meneliti langsung file NEWS dan UPGRADING dari tag RC3 mencatat bahwa beberapa perilaku (misalnya aturan pewarisan default pada parameter) berubah antara beta dan RC3. Pelajarannya: uji di RC3, tapi uji ulang di RC4 dan versi final sebelum menyatakan source code kamu 100% kompatibel.

Kapan jadwal lengkap rilis PHP 8.6?

Berikut lini masa resmi siklus rilis PHP 8.6 (sumber: wiki.php.net dan pengumuman php.net):

Bersamaan dengan RC3, tim PHP juga menandai RC untuk cabang aktif lainnya: PHP 8.5.12 RC1 dan PHP 8.4.27 RC1. Ini menandakan siklus pemeliharaan berjalan normal di semua cabang.

Apa saja yang berubah di RC3?

Karena fase RC adalah fase pembekuan fitur, jangan berharap ada fitur baru di RC3. Yang berubah adalah perbaikan bug yang ditemukan dari pengujian RC2. Daftar perubahan rinci tersedia di file NEWS dan UPGRADING di repositori php-src (atau halaman rilis di php.watch), dan angka versi RC terus bertambah justru kabar baik: artinya bug ditemukan dan diperbaiki sebelum final.

Yang justru penting diperhatikan dari RC3 adalah perubahan deprecation dan perilaku yang sudah dibekukan — inilah yang berpotensi merusak source code lama:

1. Fungsi/fitur yang dideprecate di PHP 8.6 akan memunculkan peringatan E_DEPRECATED. Di PHP 9 nanti, peringatan ini berubah menjadi error.
2. Beberapa perilaku edge-case (seperti pewarisan nilai default parameter) disempurnakan di RC3 — kode yang "kebetulan jalan" di 8.5 bisa pecah di 8.6.
3. Ekstensi pihak ketiga (PECL) tertentu belum tentu sudah punya build untuk 8.6 — ini biasanya sumber masalah terbesar saat upgrade.

Mengapa developer Indonesia harus peduli sekarang?

Ada tiga alasan konkret, bukan sekadar FOMO versi terbaru:

1. PHP 8.2 mati akhir tahun ini

PHP 8.2 mencapai end-of-life pada 31 Desember 2026 — setelah tanggal itu tidak ada lagi security fix. Data komunitas memperkirakan sekitar 1 dari 5 website berbasis PHP masih berjalan di versi yang mendekati EOL. Kalau source code yang kamu jual mensyaratkan PHP 8.2, pembelinya akan segera butuh upgrade — dan mereka akan bertanya apakah produkmu sudah teruji di versi baru.

2. Ekosistem Laravel bergerak maju

Laravel 12 membutuhkan PHP 8.2+, dan Laravel 13 membutuhkan PHP 8.3+. Trennya jelas: setiap rilis Laravel baru menaikkan syarat minimum. Source code yang "teruji kompatibel PHP 8.6" menjadi nilai jual nyata di halaman produk — pembeli technical-minded pasti mengecek bagian requirement.

3. Menemukan bug di RC itu murah, di production itu mahal

Kalau kamu menemukan bug kompatibilitas sekarang dan melaporkannya ke php-src, ada peluang diperbaiki sebelum 19 November. Kalau kamu menemukannya setelah versi final — atau lebih parah, setelah pembeli upgrade servernya — yang menanggung biaya adalah kamu.

Bagaimana cara menguji source code kamu di PHP 8.6.0 RC3?

Ikuti langkah-langkah berikut. Prinsip utamanya: uji di lingkungan terisolasi, jangan pernah di server production.

Langkah 1: Siapkan lingkungan uji terisolasi

Cara termudah adalah Docker dengan image RC resmi:

Perintah di atas me-mount folder project kamu ke container sekali pakai, lalu menampilkan versi PHP untuk memastikan kamu benar-benar menjalankan 8.6.0RC3. Tanpa Docker, kamu bisa mengunduh source tarball RC3 dari halaman download php.net dan mengompilasinya sendiri — tapi Docker jauh lebih cepat untuk sekadar uji.

Langkah 2: Verifikasi dependensi Composer

Lalu cek constraint versi PHP di composer.json:

Constraint ^8.2 berarti "≥8.2 dan <9.0", jadi PHP 8.6 otomatis tercakup — tidak perlu diubah. Yang perlu dicek justru constraint sempit seperti "php": "~8.2.0" atau "php": "8.2.*" yang akan menolak 8.6. Juga perhatikan dependensi pihak ketiga (misalnya SDK payment gateway) yang mungkin mengunci versi PHP.

Langkah 3: Jalankan test suite

Untuk project Laravel, jalankan seluruh test suite di bawah RC3. Setiap test yang hijau di 8.5 tapi merah di 8.6 adalah temuan berharga — catat, jangan diabaikan.

Langkah 4: Buru peringatan deprecation

Aktifkan error reporting penuh di .env lingkungan uji:

Lalu jalankan kembali alur kritis aplikasi (login, checkout, pembayaran, antrian, cron) sambil memantau log:

Setiap baris Deprecated: adalah utang teknis yang harus dibayar sebelum PHP 9. Dokumentasikan semuanya.

Langkah 5: Uji alur kritis secara manual

Test otomatis tidak menangkap semuanya. Buka browser, jalankan alur yang paling sering dipakai pembeli source code kamu: registrasi, login (termasuk login sosial kalau ada), tambah ke keranjang, checkout dengan payment gateway, dan unduh laporan/invoice. Kalau kamu punya panduan upgrade Laravel, pola pengujiannya mirip — bedanya kali ini yang naik versi adalah PHP-nya, bukan framework-nya.

Checklist kompatibilitas 7 poin

Simpan checklist ini dan ulangi di RC4 (22 Oktober) serta versi final (19 November):

1. Constraint PHP di composer.json mencakup 8.6 (hindari ~8.2.0 / 8.2.*).
2. Semua ekstensi PHP tersedia di build 8.6 — imagick, redis, intl, dan ekstensi PECL lain yang dipakai project. Ini sumber masalah nomor satu.
3. Nol error baru saat php artisan test dijalankan penuh.
4. Nol peringatan deprecation baru di log saat alur kritis dijalankan.
5. Library pihak ketiga (Midtrans SDK, Socialite, dsb.) sudah di versi terbaru yang mendukung PHP 8.6.
6. CI matrix ditambah PHP 8.6 — kalau kamu pakai GitHub Actions, tambah 8.6 ke matrix agar setiap push otomatis diuji.
7. README diperbarui — tulis "Teruji di PHP 8.6 (RC3)" di bagian requirement. Ini nilai jual langsung untuk produk source code kamu.

Setelah lolos semua, proses deploy ke VPS atau shared hosting tidak berubah — yang berubah hanya versi PHP yang kamu targetkan.

Batasan dan peringatan jujur

Agar tidak menyesatkan, ini hal-hal yang perlu kamu tahu:

1. RC3 bukan untuk production. Ini peringatan resmi tim PHP, bukan saran. Pakai hanya untuk uji.
2. Perilaku bisa berubah antara RC3 dan versi final. Jangan jadikan RC3 sebagai satu-satunya dasar klaim kompatibilitas — uji ulang di RC4 dan GA.
3. Cara ini tidak cocok jika project kamu bergantung pada ekstensi PECL yang belum merilis build untuk PHP 8.6. Dalam kasus itu, tunggu sampai ekstensinya tersedia, atau cari alternatif yang sudah mendukung.
4. Tidak semua deprecation bisa diperbaiki olehmu — kalau deprecation berasal dari library pihak ketiga, laporkan ke maintainer-nya atau naikkan versi library tersebut.

FAQ

Apakah PHP 8.6.0 RC3 aman dipakai di production?

Tidak. Tim PHP secara eksplisit memperingatkan untuk tidak memakai versi RC di production. Gunakan hanya di lingkungan uji terisolasi seperti Docker atau VM.

Apa bedanya RC3 dengan versi final PHP 8.6?

Fitur sudah dibekukan sejak fase beta; yang berubah di RC hanyalah perbaikan bug dan stabilitas. Versi final (19 November 2026) adalah RC terakhir yang dinyatakan stabil tanpa perubahan perilaku lagi.

Kapan PHP 8.6 versi final dirilis?

Dijadwalkan 19 November 2026. RC4 dijadwalkan 22 Oktober 2026 — masih ada satu jendela pengujian lagi sebelum final.

Apakah Laravel 12/13 kompatibel dengan PHP 8.6?

Laravel 12 membutuhkan PHP 8.2+ dan Laravel 13 membutuhkan PHP 8.3+. Secara teori keduanya bisa jalan di 8.6, tapi kompatibilitas nyata tergantung kode aplikasimu dan library pihak ketiga — makanya pengujian di RC3 penting.

Saya masih pakai PHP 8.2, apa yang harus dilakukan?

Rencanakan upgrade sebelum 31 Desember 2026 karena setelah itu tidak ada security fix. Mulai dari menguji aplikasimu di PHP 8.3/8.4 dulu, lalu 8.6. Panduan upgrade Laravel antar versi bisa jadi referensi pola kerjanya.

Di mana saya bisa mengunduh PHP 8.6.0 RC3?

Dari halaman download resmi php.net (bagian QA release) atau halaman rilis php.watch yang menyertakan changelog dan tautan unduh. Untuk uji cepat, image Docker php:8.6-rc-cli adalah cara termudah.

Apakah saya perlu mengubah composer.json untuk PHP 8.6?

Hanya jika constraint-nya sempit (misalnya ~8.2.0). Constraint umum seperti ^8.2 sudah mencakup 8.6 secara otomatis. Yang lebih penting adalah memastikan setiap dependensi juga mendukung PHP 8.6.

Kesimpulan: PHP 8.6.0 RC3 yang rilis 8 Oktober 2026 adalah sinyal bahwa versi final tinggal sekitar enam minggu lagi. Enam minggu adalah waktu yang cukup untuk menguji, menemukan, dan memperbaiki masalah kompatibilitas — tapi hanya kalau kamu mulai sekarang. Uji di RC3, ulangi di RC4 tanggal 22 Oktober, dan sambut 19 November dengan source code yang siap. Kalau kamu butuh gambaran tren stack yang dipakai developer Indonesia tahun ini, baca juga tech stack populer 2026.