Fase 10 · Enterprise & Capstone

Strategi upgrade & versi

Aplikasi yang tertinggal beberapa versi mayor bukan gagal karena satu keputusan besar, melainkan karena ratusan keputusan kecil untuk menundanya. Menjaganya tetap terkini jauh lebih murah daripada mengejar ketertinggalan.

Sumber asli laravel.com Resmi Rangkuman ~6 menit baca

Intisari

Rilis mayor setiap tahun sekitar Q1; perbaikan bug 18 bulan, perbaikan keamanan 2 tahun.
Rilis minor dan patch tidak pernah memuat perubahan yang memutus — aman diotomatiskan.
Laravel 13 sengaja meminimalkan perubahan yang memutus; sebagian besar aplikasi bisa naik tanpa banyak mengubah kode.
Laravel Shift mengotomatiskan sebagian besar pekerjaan mekanisnya.
Yang menentukan lancar-tidaknya upgrade adalah suite tes dan jumlah paket pihak ketiga.

Kalender rilis

Versi	PHP	Rilis	Perbaikan bug	Perbaikan keamanan
11	8.2 – 8.4	12 Mar 2024	3 Sep 2025	12 Mar 2026
12	8.2 – 8.5	24 Feb 2025	13 Agu 2026	24 Feb 2027
13	8.3 – 8.5	17 Mar 2026	Q3 2027	17 Mar 2028

Kolom terakhir adalah tenggat yang sesungguhnya. Setelah tanggal itu, kerentanan keamanan yang ditemukan tidak akan diperbaiki untuk versimu. Untuk aplikasi yang menangani data pengguna, berjalan di atas versi yang tidak lagi menerima perbaikan keamanan adalah risiko yang biasanya tidak diterima oleh audit apa pun. Rencanakan upgrade sebelum tanggal itu, bukan sesudah.

Tiga jenis pembaruan

Jenis	Contoh	Risiko	Cara
Patch	13.2.4 → 13.2.5	Sangat rendah	Otomatis, mingguan
Minor	13.2 → 13.5	Rendah	Otomatis, dengan tes sebagai gerbang
Mayor	12 → 13	Sedang	Cabang khusus, terencana

composer update --with-all-dependencies    # dalam batas ^13.0 — aman
composer outdated --direct                 # apa yang tertinggal

Otomatiskan patch dan minor. Dependabot atau Renovate yang membuka pull request mingguan, dengan suite tes sebagai gerbang, membuat pembaruan kecil menjadi rutinitas yang tidak perlu dipikirkan. Yang mahal bukan sepuluh pembaruan kecil yang dilakukan tepat waktu — melainkan satu pembaruan besar yang menumpuk dua tahun.

Alur upgrade mayor

Baca panduan upgrade resminya dari awal sampai akhir. Ia mengelompokkan perubahan berdasarkan kemungkinan dampaknya.
Pastikan suite tes hijau di versi lama. Jangan pernah mulai upgrade dengan tes yang merah.
Buat cabang khusus. Naikkan versi PHP lebih dulu kalau memang diperlukan.
Naikkan laravel/framework dan paket pihak pertama bersamaan.
Perbaiki sampai composer update berhasil, lalu sampai tes hijau, lalu sampai PHPStan hijau.
Jalankan di staging dengan lalu lintas yang menyerupai produksi.
Rilis dengan rencana rollback yang jelas — revisi task definition sebelumnya.

composer require laravel/framework:^13.0 --with-all-dependencies
php artisan test
./vendor/bin/phpstan analyse
./vendor/bin/pint

Yang biasanya jadi penghambat

Penghambat	Pencegahan
Paket pihak ketiga yang belum mendukung	Pilih paket yang terpelihara; periksa riwayat rilisnya sebelum memasang
Paket yang sudah ditinggalkan	Ganti sebelum ia jadi penghalang
Suite tes yang tipis	Ini investasi yang terbayar persis di momen ini
Kode yang bergantung pada internal framework	Pakai API publik; jangan mewarisi kelas internal
Versi PHP yang tertinggal	Naikkan PHP secara terpisah, sebelum menaikkan Laravel

Paket pihak ketiga adalah penyebab nomor satu upgrade yang tertunda. Sebelum memasang paket baru, periksa tiga hal: kapan rilis terakhirnya, apakah ia sudah mendukung versi Laravel terkini, dan berapa lama jeda antara rilis Laravel dan dukungannya pada upgrade sebelumnya. Paket yang butuh enam bulan untuk mendukung versi baru akan menahan seluruh aplikasimu selama enam bulan itu.

Laravel Shift

Layanan berbayar yang mengotomatiskan sebagian besar pekerjaan mekanis upgrade dan menghasilkan pull request. Ia tidak menyelesaikan segalanya — perubahan yang bergantung pada logika aplikasi tetap perlu tangan manusia — tapi ia menyelesaikan bagian yang membosankan dan mudah terlewat. Untuk lompatan beberapa versi sekaligus, biayanya biasanya jauh lebih kecil daripada waktu yang dihemat.

Menjaga agar tidak tertinggal lagi

Jadwalkan upgrade mayor sebagai pekerjaan rutin tahunan, bukan sebagai proyek yang harus disetujui.
Lakukan dalam beberapa bulan setelah rilis — saat itu ekosistem paket sudah menyusul, tapi kamu belum tertinggal.
Otomatiskan pembaruan patch dan minor sepenuhnya.
Jaga suite tes tetap bermakna; ia adalah alat upgrade-mu yang sesungguhnya.
Catat setiap penyimpangan dari konvensi Laravel — di situlah upgrade akan tersandung.
Naikkan versi PHP secara terpisah dari versi Laravel; dua perubahan besar sekaligus menyulitkan diagnosis.

Kalimat yang layak diingat: biaya upgrade tumbuh lebih cepat daripada linear terhadap waktu yang ditunda. Naik satu versi biasanya pekerjaan beberapa hari; naik empat versi sekaligus adalah proyek berbulan dengan risiko yang jauh lebih besar — karena kamu tidak lagi bisa membedakan mana kerusakan yang berasal dari perubahan yang mana.

Latihan: jalankan composer outdated --direct pada proyekmu dan catat paket mana yang tertinggal versi mayor. Untuk setiap paket, cek kapan rilis terakhirnya. Daftar yang kamu dapat adalah peta risiko upgrade proyekmu — dan biasanya lebih pendek, tapi lebih mengkhawatirkan, daripada dugaan.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.