Linux 7.3.1 Rilis, Longterm 6.18.60 dan 6.12.115 Ikut Diperbarui

Linux 7.3.1 masuk kanal stable pada 30 Oktober 2026, bersamaan dengan pembaruan tiga cabang longterm: 6.18.60, 6.12.115, dan 6.6.161. Dua hari kemudian, 1 November 2026, kernel.org mencatat rilis 7.2.15 untuk cabang 7.2 dan kandidat 7.4-rc1 di jalur mainline. Semua tanggal dan nomor versi di artikel ini diambil langsung dari berkas releases.json milik kernel.org pada 6 November 2026, bukan dari catatan rilis pihak ketiga.

TL;DR

• Linux 7.3.1 (stable) terbit 30 Oktober 2026, disusul 7.2.15 pada 1 November 2026 untuk cabang 7.2.
• Jalur mainline sudah masuk 7.4-rc1, artinya jendela merge 7.4 sudah ditutup dan tahap pengujian berjalan.
• Tiga cabang longterm diperbarui serentak pada 30 Oktober 2026: 6.18.60, 6.12.115, dan 6.6.161.
• Server produksi umumnya memilih cabang longterm karena menerima patch lebih panjang dibanding cabang stable biasa.
• Upgrade kernel yang aman dimulai dari membaca log stable, menyiapkan initramfs, dan menyimpan kernel lama sebagai jalur mundur.

Bagi tim yang mengelola server, pertanyaan sebenarnya bukan sekadar versi terbaru apa, tapi cabang mana yang harus dipasang dan kapan. Kernel.org memisahkan setiap rilis ke dalam tiga label: mainline, stable, dan longterm. Label itu yang menentukan seberapa sering pembaruan datang dan seberapa lama sebuah cabang masih dirawat.

Artikel ini membahas pola rilis kernel Linux per November 2026, perbedaan tiap kanal, dan prosedur upgrade yang bisa dipertanggungjawabkan di server produksi. Semua angka berasal dari data rilis resmi yang bisa dibuka ulang.

Apa bedanya mainline, stable, dan longterm di kernel.org?

Mainline adalah jalur pengembangan utama yang menerima fitur baru, sedangkan stable menampung perbaikan bug untuk versi yang sudah dilepas, dan longterm adalah cabang stable yang masa perawatannya diperpanjang. Pada data 6 November 2026, label mainline melekat pada 7.4-rc1, label stable pada 7.3.1 dan 7.2.15, dan label longterm pada 6.18.60, 6.12.115, serta 6.6.161.

Perbedaan ini penting karena konsekuensinya berbeda untuk tiap jenis mesin. Laptop pengembangan bisa mengikuti mainline tanpa risiko besar, sementara server yang menjalankan layanan publik lebih rasional mengikuti longterm. Alasan utamanya bukan soal versi lebih baru atau lebih lama, tapi soal seberapa sering pembaruan keamanan datang ke cabang yang dipakai.

Perlu dicatat, jumlah cabang longterm yang aktif berubah dari waktu ke waktu. Kernel.org selalu mencantumkan daftar terkini di halaman kategori rilis, dan daftar itulah yang sebaiknya dijadikan acuan, bukan daftar yang dihafal dari artikel lama.

Berapa cabang yang diperbarui pada Oktober sampai November 2026?

Pada 30 Oktober 2026 kernel.org mencatat empat rilis dalam satu hari: 7.3.1 sebagai stable, plus 6.18.60, 6.12.115, dan 6.6.161 sebagai longterm. Dua hari berselang, 1 November 2026, ada dua catatan lagi yaitu 7.2.15 dan 7.4-rc1.

Pola ini menunjukkan satu hal yang sering salah dipahami: pembaruan kernel tidak selalu berarti fitur baru. Ketika satu cabang stable dan tiga cabang longterm naik versi di hari yang sama, isinya hampir selalu perbaikan, bukan penambahan kemampuan. Bagi operator, angka yang relevan justru jumlah cabang yang masih menerima patch, karena itu menentukan berapa lama sistem bisa tetap dirawat tanpa migrasi besar.

Berikut ringkasan data rilis yang tercatat pada 6 November 2026:

Versi	Kanal	Tanggal rilis	Catatan
7.4-rc1	mainline	2026-11-01	Kandidat rilis pertama untuk 7.4
7.3.1	stable	2026-10-30	Patch pemeliharaan cabang 7.3
7.2.15	stable	2026-11-01	Cabang 7.2 masih dirawat
6.18.60	longterm	2026-10-30	Cabang longterm generasi 6.18
6.12.115	longterm	2026-10-30	Cabang longterm generasi 6.12
6.6.161	longterm	2026-10-30	Cabang longterm generasi 6.6

Tabel di atas hanya memuat enam entri teratas dari berkas rilis. Halaman resmi memuat daftar lengkap termasuk arsip cabang yang sudah tidak dirawat, dan itu sebabnya pengecekan langsung ke sumber lebih aman daripada mengandalkan ringkasan.

Harus pilih kernel mana untuk server produksi?

Untuk server produksi, cabang longterm adalah pilihan default yang paling mudah dipertanggungjawabkan karena menerima patch lebih lama. Dari data di atas, longterm yang aktif mencakup 6.18, 6.12, dan 6.6, sehingga tim bisa memilih generasi yang kompatibel dengan driver dan modul yang dipakai.

Ada tiga pertimbangan yang biasanya menentukan pilihan. Pertama, dukungan perangkat keras: server baru dengan CPU atau NIC generasi terbaru kadang butuh kernel lebih baru agar driver tersedia. Kedua, dukungan vendor: sebagian distro hanya mengirim kernel dari cabang tertentu. Ketiga, kebijakan internal: kalau tim punya jadwal pemeliharaan bulanan, cabang stable dengan siklus rilis rapat justru lebih cocok karena pembaruannya lebih sering dan lebih kecil.

Yang sebaiknya dihindari adalah mencampur dua kebiasaan sekaligus: memakai mainline karena ingin fitur terbaru, lalu mengeluh ketika API internal berubah. Mainline memang menerima perubahan yang belum stabil. Kalau mesin itu menjalankan basis data atau layanan dengan SLA, longterm tetap pilihan yang lebih tenang.

Bagaimana prosedur upgrade kernel yang aman?

Prosedur yang aman selalu menyertakan jalur mundur: catat versi yang sedang berjalan, pastikan paket kernel lama tetap terpasang, lalu uji boot sebelum mengganti konfigurasi bootloader secara permanen. Tanpa jalur mundur, satu kegagalan boot berubah menjadi pemulihan darurat.

Urutan kerja yang bisa dipakai:

1. Catat versi aktif dan konfigurasi bootloader sebelum menyentuh apa pun, lalu simpan keluarannya ke berkas.
2. Baca log perubahan cabang yang dituju lewat pohon stable di git.kernel.org agar tahu perbaikan apa yang masuk.
3. Pasang paket kernel baru tanpa menghapus kernel lama, sehingga entri boot lama tetap tersedia.
4. Bangun ulang initramfs sesuai prosedur distro, karena modul tambahan seperti penyimpanan atau jaringan sering butuh regenerasi.
5. Boot ke kernel baru, periksa keluaran pesan kernel untuk error driver, lalu jalankan beban kerja nyata sebelum menandai perubahan selesai.
6. Simpan kernel lama minimal sampai satu siklus pemeliharaan lewat, baru bersihkan.

Langkah nomor dua sering dilewati padahal murah. Membaca log stable memberi tahu apakah pembaruan menyentuh subsistem yang dipakai, misalnya penyimpanan, jaringan, atau virtualisasi. Kalau tidak ada yang relevan, upgrade bisa dijadwalkan di jendela pemeliharaan biasa. Kalau ada perbaikan keamanan yang menyentuh layanan publik, jadwalnya didahulukan.

Setelah boot, verifikasi sederhana tetap perlu. Periksa versi yang benar-benar berjalan, baca keluaran pesan kernel untuk baris berlabel error atau warning, dan pastikan modul yang dipakai benar-benar termuat. Kernel yang berhasil boot tapi kehilangan satu modul penyimpanan bisa tampak sehat sampai beban nyata datang, dan pada titik itu penyebabnya jauh lebih sulit dilacak karena perubahan yang baru dilakukan sudah bercampur dengan efek beban.

Ada satu kebiasaan yang perlu dihindari: menganggap nomor versi lebih tinggi selalu lebih aman. Kernel 7.3.1 memang lebih baru dari 6.18.60, tetapi keduanya berada di kanal berbeda dengan kebijakan perawatan berbeda. Membandingkan hanya dari angka versi akan menghasilkan keputusan yang salah konteks.

Untuk mesin virtual dan container host, perhatian tambahan ada pada modul eksternal. Driver pihak ketiga yang dibangun di luar pohon kernel harus disesuaikan setiap kali nomor versi berubah. Karena itu, di lingkungan dengan banyak host, mengunci satu cabang longterm untuk seluruh armada biasanya lebih murah daripada membiarkan tiap host mengikuti versi masing-masing.

Kapan pembaruan kernel sebaiknya ditunda?

Pembaruan sebaiknya ditunda ketika host sedang menanggung beban puncak, ketika tim belum punya jalur mundur yang teruji, atau ketika modul pihak ketiga belum mendukung versi baru. Menunda dengan alasan yang jelas berbeda dengan menunda karena lupa, dan yang kedua inilah yang biasanya berakhir dengan patch keamanan tertinggal berbulan-bulan.

Penundaan yang wajar biasanya berumur pendek. Contohnya, host basis data menunggu jendela pemeliharaan akhir pekan, atau host dengan driver RAID khusus menunggu vendor merilis modul yang cocok. Penundaan yang tidak wajar adalah menunggu sampai muncul insiden, karena pada titik itu pilihan yang tersedia sudah menyempit menjadi dua: pemulihan cepat dengan risiko, atau pemulihan lambat dengan downtime panjang.

Ada juga situasi ketika upgrade justru tidak diperlukan sama sekali. Kalau host menjalankan kernel dari distro dan distro tersebut membackport patch keamanan ke versi yang sudah terpasang, mengikuti nomor versi kernel.org tidak menambah keamanan apa pun. Yang menentukan adalah isi patch pada kernel yang benar-benar berjalan, bukan nomor versi di halaman unduhan. Karena itu, memeriksa catatan pembaruan distro jauh lebih berguna daripada membandingkan nomor versi mentah.

Pada lingkungan virtualisasi, kernel host dan kernel tamu perlu diperlakukan terpisah. Hypervisor bisa tetap di cabang longterm bertahun-tahun sementara tamu mengikuti cabang yang lebih baru untuk kebutuhan perangkat lunak di dalamnya. Mencampur keduanya dalam satu jadwal pembaruan biasanya menciptakan pekerjaan tambahan yang tidak perlu, terutama ketika satu pembaruan host memaksa semua tamu di-reboot.

Untuk armada yang besar, keputusan yang paling berpengaruh bukan versi mana yang dipilih, tapi seberapa seragam pilihan itu. Armada yang semua hostnya berada di cabang longterm yang sama bisa diuji sekali dan digulirkan berkali-kali. Armada yang tiap hostnya punya versi berbeda menuntut pengujian per host, dan biaya itu biasanya yang membuat jadwal pemeliharaan tertunda terus.

FAQ

Apakah Linux 7.3.1 sudah bisa dipakai di server produksi?

Bisa, tetapi 7.3 adalah cabang stable, bukan longterm. Untuk server dengan SLA panjang, cabang longterm seperti 6.18 atau 6.12 umumnya lebih tepat karena menerima patch lebih lama. Keputusan akhir tetap bergantung pada dukungan driver dan kebijakan distro yang dipakai.

Apa arti label 7.4-rc1 pada data kernel.org?

rc1 berarti kandidat rilis pertama untuk versi 7.4, diambil dari jalur mainline setelah jendela merge ditutup. Label ini menandakan tahap pengujian, bukan rilis final, sehingga tidak disarankan untuk sistem yang menuntut stabilitas tinggi.

Berapa lama satu cabang longterm dirawat?

Durasi perawatan tiap cabang berbeda dan ditetapkan oleh pemelihara kernel. Karena itu artikel ini tidak mencantumkan angka pasti tanpa sumber, dan pembaca sebaiknya memeriksa daftar rilis terbaru di kernel.org untuk melihat cabang mana yang masih aktif.

Apakah pembaruan kernel selalu menambah fitur baru?

Tidak. Rilis pada cabang stable dan longterm umumnya berisi perbaikan bug dan penyesuaian keamanan. Penambahan fitur terjadi di jalur mainline, sehingga nomor versi yang naik di cabang stable tidak berarti ada kemampuan baru.