Linux 7.3.3 dan Lima Longterm Diperbarui Serentak 6 November 2026

Pada 6 November 2026 kernel.org mencatat Linux 7.3.3 di kanal stable, bersamaan dengan lima pembaruan cabang longterm: 6.18.62, 6.12.116, 6.6.162, 6.1.192, dan 5.15.225. Semua nomor versi dan tanggal di artikel ini dibaca langsung dari berkas releases.json milik kernel.org pada 7 November 2026, bukan dari ringkasan pihak ketiga. Artinya, dalam satu hari ada enam rilis kernel di dua jalur perawatan yang berbeda. Bagi tim yang mengelola server, pertanyaannya bukan versi terbaru apa, melainkan cabang mana yang dipakai dan kapan harus pindah.

TL;DR

• Linux 7.3.3 terbit 6 November 2026 di kanal stable, disusul 7.2.15 pada 1 November 2026 untuk cabang 7.2.
• Lima cabang longterm diperbarui pada hari yang sama: 6.18.62, 6.12.116, 6.6.162, 6.1.192, dan 5.15.225.
• Jalur mainline sudah masuk 7.4-rc1 sejak 1 November 2026, jadi jendela merge 7.4 sudah ditutup.
• Server produksi umumnya memilih longterm karena patch keamanan datang ke cabang yang sama lebih lama.
• Prosedur upgrade yang aman dimulai dari membaca log rilis, menyiapkan initramfs, lalu menyimpan kernel lama sebagai jalur mundur.

Kernel Linux punya tiga label rilis yang sering dicampur dalam percakapan sehari-hari: mainline, stable, dan longterm. Ketiganya bukan tingkatan kualitas, melainkan perbedaan kontrak perawatan. Label itu yang menentukan seberapa sering pembaruan datang dan berapa lama sebuah cabang masih menerima perbaikan. Artikel ini membedah data rilis per 6 November 2026, lalu menurunkan keputusan praktis untuk mesin produksi dan mesin pengembangan.

Kanal kernel apa saja yang diperbarui pada 6 November 2026?

Ada enam rilis di dua jalur perawatan pada tanggal itu: satu di kanal stable versi 7.3.3, dan lima di kanal longterm versi 6.18.62, 6.12.116, 6.6.162, 6.1.192, serta 5.15.225. Kanal mainline tidak menerima rilis stabil hari itu karena posisinya sedang dipegang 7.4-rc1 yang terbit 1 November 2026.

Pola ini penting dibaca sebagai sinyal ritme, bukan sekadar pengumuman versi. Enam rilis dalam satu hari berarti pohon kernel sedang membersihkan tumpukan perbaikan di beberapa cabang sekaligus. Untuk operator, yang perlu diperiksa bukan hanya nomor versi terbaru, tapi apakah cabang yang sedang dipakai termasuk di dalam daftar itu.

Rincian per kanal pada 6 November 2026 bisa dilihat di tabel berikut. Kolom ritme diisi berdasarkan posisi versi pada data rilis yang sama, bukan estimasi.

Kanal	Versi per 6 November 2026	Tanggal rilis	Profil pemakaian
mainline	7.4-rc1	1 November 2026	Uji coba fitur baru, mesin pengembangan
stable	7.3.3	6 November 2026	Desktop dan server yang mengikuti versi terbaru
stable	7.2.15	1 November 2026	Mesin yang belum pindah ke 7.3
longterm	6.18.62	6 November 2026	Server produksi baru
longterm	6.12.116	6 November 2026	Server produksi berumur satu sampai dua tahun
longterm	6.6.162	6 November 2026	Server lama yang sulit di-upgrade
longterm	6.1.192	6 November 2026	Perangkat tertanam dan appliance
longterm	5.15.225	6 November 2026	Sistem yang masih terikat driver lama

Berapa lama sebuah cabang kernel masih dirawat?

Berkas releases.json tidak mencantumkan tanggal akhir perawatan, melainkan daftar cabang yang masih aktif pada saat berkas itu diperbarui. Cabang yang berhenti dirawat akan hilang dari daftar tersebut, sehingga cara paling akurat memeriksa umur sebuah cabang adalah membandingkan daftar hari ini dengan daftar bulan lalu, bukan menghafal tanggal dari artikel lama.

Pada 6 November 2026 daftar longterm berisi lima cabang, dari 6.18.62 sampai 5.15.225. Jarak antara cabang tertinggi dan terendah di daftar itu menunjukkan satu hal yang sering terlewat: kernel tidak memaksa semua orang berada di versi yang sama. Selama sebuah cabang masih muncul di daftar longterm, cabang itu masih menerima perbaikan, sekalipun nomor versinya terlihat jauh di belakang.

Konsekuensinya untuk perencanaan kapasitas cukup jelas. Tim yang memakai 5.15.225 punya alasan kuat untuk menyusun rencana pindah, bukan karena versinya buruk, tapi karena setiap cabang di daftar itu pada akhirnya akan keluar. Yang bisa dilakukan sekarang adalah menyiapkan jalur upgrade selama masih ada waktu, bukan setelah cabangnya hilang dari daftar.

Daftar cabang yang masih dirawat selalu tersedia di halaman kategori rilis kernel.org. Halaman itu juga menautkan arsip tarball per cabang, sehingga verifikasi bisa dilakukan tanpa perantara.

Kapan server produksi sebaiknya pindah cabang kernel?

Server produksi sebaiknya tidak pindah cabang setiap ada rilis baru. Pindah cabang hanya masuk akal dalam tiga situasi: cabang yang dipakai keluar dari daftar perawatan, ada driver atau fitur yang hanya tersedia di cabang lebih baru, atau muncul kerentanan yang perbaikannya tidak masuk ke cabang lama.

Di luar tiga situasi itu, tindakan yang benar adalah tetap di cabang yang sama dan memasang patch terbaru untuk cabang tersebut. Contoh nyata ada pada data 6 November 2026: pengguna 6.12 cukup memasang 6.12.116, dan pengguna 6.18 cukup memasang 6.18.62. Tidak ada keharusan melompat ke 7.3.3 hanya karena nomornya lebih tinggi.

Alasan utamanya adalah biaya perubahan. Setiap lompatan cabang membawa perubahan internal yang tidak terlihat di changelog ringkas: perilaku scheduler, default parameter I/O, sampai perubahan pada driver penyimpanan. Di mesin yang menjalankan basis data atau hypervisor, perubahan seperti itu butuh jendela uji tersendiri. Memasang patch dalam cabang yang sama jauh lebih murah karena ruang perubahan yang tersentuh lebih sempit.

Bagaimana urutan upgrade kernel yang aman?

Urutan yang aman dimulai dari membaca changelog cabang yang dituju, bukan langsung mengeksekusi perintah paket. Dari changelog itu bisa dilihat apakah ada perubahan yang menyentuh driver, sistem berkas, atau parameter boot yang dipakai mesin tersebut.

1. Catat versi kernel yang sedang berjalan dengan perintah uname -r, lalu simpan keluarannya di catatan deployment.
2. Baca changelog cabang tujuan dan tandai bagian yang menyentuh perangkat keras atau sistem berkas yang dipakai.
3. Pastikan paket kernel lama masih terpasang, sehingga entri boot lama tetap tersedia sebagai jalur mundur.
4. Pasang paket kernel baru beserta paket header dan modul tambahan yang dipakai, misalnya modul sistem berkas jaringan.
5. Bangun ulang initramfs sesuai kebutuhan distribusi, lalu periksa bahwa berkas initramfs baru benar-benar terbentuk.
6. Reboot, lalu verifikasi dengan uname -r bahwa kernel yang berjalan memang versi baru.
7. Periksa log ringkas boot untuk modul yang gagal dimuat, dan uji layanan utama sebelum menutup jendela perubahan.
8. Baru setelah layanan stabil, pertimbangkan menghapus kernel lama. Jangan menghapusnya di hari yang sama.

Langkah ketujuh sering dilewati. Kernel yang berhasil boot belum tentu membawa semua modul yang dibutuhkan layanan, terutama pada mesin dengan perangkat jaringan khusus atau filesystem eksotis. Modul yang gagal dimuat biasanya muncul sebagai baris error di log boot, dan baris itu yang menentukan apakah rollback perlu dilakukan.

Untuk verifikasi sumber, riwayat commit per cabang tersedia di repositori stable kernel.org. Aturan perawatan cabang stable dijelaskan di dokumentasi proses kernel, dan aturan itulah yang membedakan patch yang boleh masuk cabang stable dari yang harus menunggu siklus mainline.

Apa arti 7.4-rc1 bagi pengguna kernel stable?

7.4-rc1 yang terbit 1 November 2026 menandai bahwa jendela merge untuk 7.4 sudah ditutup dan tahap pengujian dimulai. Selama tahap ini, mainline hanya menerima perbaikan bug dan regresi, bukan fitur baru. Bagi pengguna stable, artinya sederhana: tidak ada yang perlu dilakukan sekarang, dan perubahan besar berikutnya baru relevan ketika 7.4 keluar sebagai rilis stabil.

Yang menarik dari data 6 November 2026 adalah jarak antar jalur. Mainline berada di 7.4-rc1, stable di 7.3.3, dan longterm tertinggi di 6.18.62. Jarak antara mainline dan longterm tertinggi mencapai lebih dari satu nomor minor, dan jarak itu normal. Kernel tidak berjalan dengan satu versi tunggal, karena setiap jalur melayani kebutuhan perawatan yang berbeda.

Konsekuensi praktisnya ada pada cara membaca pengumuman keamanan. Ketika sebuah kerentanan diumumkan, perbaikannya biasanya masuk lebih dulu ke mainline, lalu ke cabang stable, lalu ke cabang longterm yang masih dirawat. Urutan itu menjelaskan mengapa sebuah perbaikan bisa sudah ada di 7.3.3 tetapi belum muncul di 6.6.162 pada hari yang sama. Selisih beberapa hari antara jalur bukan tanda kelalaian, melainkan hasil pengujian yang berbeda di tiap cabang.

Bagi tim yang menyusun jadwal pemeliharaan, urutan itu bisa dipakai sebagai acuan. Jika sebuah perbaikan keamanan sudah masuk cabang mainline tetapi belum masuk cabang longterm yang dipakai, langkah yang masuk akal adalah memantau pengumuman cabang tersebut, bukan langsung memasang tarball mainline. Memasang mainline di server produksi berarti keluar dari jalur perawatan yang justru ingin dipakai.

Ada satu kebiasaan lama yang perlu dipertahankan: mencatat versi kernel bersama tanggal pemasangan. Tanpa catatan itu, pertanyaan sederhana seperti "apakah mesin ini sudah menerima patch keamanan bulan lalu" tidak bisa dijawab tanpa masuk ke tiap mesin satu per satu. Pada mesin yang jumlahnya lebih dari sepuluh, selisih informasi seperti itu jauh lebih mahal daripada waktu yang dipakai untuk mencatat.

FAQ

Apakah 7.3.3 wajib dipasang di server produksi?

Tidak. Server produksi yang berjalan di cabang longterm cukup memasang patch terbaru cabang tersebut. Pada 6 November 2026, pengguna 6.18 cukup memasang 6.18.62. Pindah ke 7.3.3 adalah keputusan terpisah yang butuh pengujian sendiri.

Berapa jumlah cabang longterm yang aktif sekarang?

Pada 6 November 2026 ada lima cabang longterm aktif: 6.18.62, 6.12.116, 6.6.162, 6.1.192, dan 5.15.225. Jumlah ini berubah dari waktu ke waktu, jadi angka yang berlaku adalah yang tercantum di releases.json saat diperiksa.

Apakah rilis kandidat 7.4-rc1 layak dipakai?

Layak untuk pengujian dan pelaporan bug, bukan untuk layanan publik. Rilis kandidat masih menerima perubahan antarmuka dan perbaikan besar antar versi rc, sehingga hasil pengujian di satu rc belum tentu berlaku di rc berikutnya.

Di mana melihat isi perubahan tiap versi kernel?

Changelog resmi ada di halaman kategori rilis kernel.org, dan riwayat commit lengkap ada di repositori stable kernel.org. Keduanya sumber primer, sehingga aman dipakai sebagai rujukan saat menyusun catatan perubahan internal.

Rekomendasi Tools & Layanan

Mau langsung nyobain AI yang dibahas di artikel ini tanpa setup ribet? AI token plan Alibaba Cloud ngasih akses ke Qwen, DeepSeek, dan model lain lewat satu API, dan platform Qwen buat build agent sendiri. Free tier-nya cukup buat eksperimen pertama.