Masalah klasik upgrade bukan cuma mencari waktu, tapi mengingat kapan tenggatnya. Node 24 mulai tidak disupport kapan? Python 3.13 masih dapat security fix sampai kapan? Pertanyaan itu punya jawaban yang tersedia secara machine-readable, dan tidak perlu dihafal. Situs endoflife.date menyediakan seluruh datanya sebagai JSON, satu endpoint per produk. Tabel di artikel ini ditarik sendiri pada 21 September 2026 lewat endpoint tersebut, jadi semua angkanya bisa diulang dengan command yang sama.
TL;DR
- Situs endoflife.date menyediakan tanggal end-of-life berbagai produk sebagai JSON melalui endpoint seperti https://endoflife.date/api/nodejs.json, satu endpoint per produk.
- Tabel data dalam artikel ditarik pada 21 September 2026, misalnya Node.js 26 memiliki versi terbaru 26.9.0 dengan EOL 2029-04-30 dan PostgreSQL 18 versi 18.6 dengan EOL 2030-11-14.
- Nilai eol berupa false pada JSON berarti sumber belum memiliki tanggal end-of-life untuk siklus tersebut, bukan berarti produk tidak akan pernah usang.
- Tanggal support dan tanggal EOL itu berbeda: Node 24 berakhir support pada 2026-10-20 tetapi EOL-nya baru 2028-04-30, sehingga kalender upgrade sebaiknya berpijak pada tanggal support.
- Untuk instalasi baru, siklus genap Node.js yang memiliki tanggal LTS seperti 24 dan 26 menjadi kandidat default, sementara Ubuntu 26.04 LTS dengan EOL 2031-05-29 lebih cocok untuk server yang jarang direinstal.
Dipakai dulu, baru dibaca detailnya
Endpoint-nya mengikuti pola sederhana:
curl -s https://endoflife.date/api/nodejs.json | jq ".[0:4]"Hasilnya adalah array satu objek per rilis mayor, dengan field seperti cycle, latest, eol, support, dan lts. Untuk Ubuntu, ganti nama produknya:
curl -s https://endoflife.date/api/ubuntu.json | jq -r ".[] | [.cycle, .latest, .eol, .lts] | @tsv"Field cycle bukan versi penuh, melainkan nomor rilis mayor, sedangkan latest berisi versi patch terbaru yang tercatat saat itu. Jadi kalau produksi jalan di Node 24.13.2 dan latest menunjukkan 24.21.0, itu sinyal bahwa ada belasan rilis patch yang belum dipakai, bukan sinyal langsung bahwa versi lo rentan.
Tabel yang ditarik hari ini
Angka di bawah ini hasil query 21 September 2026, kolom terakhir adalah tanggal end-of-life menurut sumber yang sama.
| Produk | Rilis | Versi terbaru tercatat | EOL |
|---|---|---|---|
| Node.js | 26 | 26.9.0 | 2029-04-30 |
| Node.js | 25 | 25.9.0 | 2026-06-01, sudah lewat |
| Node.js | 24 | 24.21.0 | 2028-04-30, support sampai 2026-10-20 |
| Python | 3.14 | 3.14.7 | 2030-10-31 |
| Python | 3.13 | 3.13.15 | 2029-10-31, support sampai 2026-10-01 |
| Python | 3.12 | 3.12.14 | 2028-10-31 |
| Python | 3.11 | 3.11.16 | 2027-10-31 |
| PostgreSQL | 18 | 18.6 | 2030-11-14 |
| PostgreSQL | 17 | 17.11 | 2029-11-08 |
| PostgreSQL | 16 | 16.15 | 2028-11-09 |
| PostgreSQL | 15 | 15.19 | 2027-11-11 |
| Ubuntu | 26.04 LTS | 26.04.1 | 2031-05-29 |
| Ubuntu | 25.10 | 25.10 | 2026-07-01, sudah lewat |
| OpenSSL | 3.5 LTS | 3.5.8 | 2030-04-08 |
| OpenSSL | 3.4 | 3.4.7 | 2026-10-22 |
| Go | 1.27 | 1.27.1 | belum ada tanggal |
| Go | 1.26 | 1.26.8 | belum ada tanggal |
| Go | 1.25 | 1.25.14 | 2026-08-19, sudah lewat |
| MySQL | 9.7 LTS | 9.7.2 | 2034-04-21 |
| Redis | 8.10 | 8.10.2 | belum ada tanggal |
Field false dan null itu bukan tanpa arti
Ini bagian yang paling sering bikin salah baca. Pada JSON, eol bisa bernilai tanggal ISO, false, atau string. Nilai false berarti sumber belum punya tanggal end-of-life untuk siklus itu, bukan berarti produk tidak akan pernah usang. Di data yang sama, siklus nginx 1.31 dan 1.30 bernilai false, sementara 1.29 bertanggal 2026-05-13. Untuk Redis, yang tersedia justru field support: siklus 8.8 tercatat selesai masa support pada 2026-07-29 dan 8.6 pada 2026-05-25, sedangkan 8.10 masih berstatus didukung.
Bedanya penting saat dipakai di script. Kalau pipeline lo membandingkan tanggal dengan naive parsing, false bisa berubah menjadi error, yang lebih buruk lagi bisa dianggap "tidak ada tenggat" lalu hilang dari laporan. Aturan amannya: perlakukan tanggal sebagai satu-satunya sinyal yang bisa dipakai otomatisasi tanpa penilaian manusia, dan perlakukan selain tanggal sebagai "perlu dicek ke sumber vendor".
Jebakan kedua: support dan eol bukan hal yang sama
Node.js 24 adalah contoh paling jelas. Di data yang ditarik hari ini, Node 24 berstatus LTS dengan tanggal mulai LTS 2025-10-28, masa support berakhir 2026-10-20, dan eol baru jatuh 2028-04-30. Artinya ada rentang hampir dua tahun di mana rilis itu masih dapat security fix, tapi tidak lagi dapat update fitur atau dukungan reguler. Banyak tim salah membaca ini sebagai "masih aman sampai 2028", padahal kalender upgrade yang sehat berpijak pada tanggal support, bukan tanggal eol.
Untuk yang suka angka konkret dari data hari ini: Node 26 mulai jadi LTS pada 2026-10-28, jadi rencana upgrade ke generasi baru idealnya disusun sebelum akhir Oktober. Node 25 tercatat sudah lewat tanggal EOL pada 2026-06-01, sehingga kalau masih ada image yang memakai siklus itu, itu temuan, bukan rencana masa depan.
Script 20 baris untuk inventaris
Inti automasinya cuma perlu tiga kemampuan: ambil JSON, cocokkan dengan versi terpasang, cetak selisih tanggal. Contoh minimal yang bisa ditempel ke cron:
for p in nodejs python postgresql ubuntu openssl go; do
curl -s "https://endoflife.date/api/$p.json" -o "/tmp/eol-$p.json"
done
jq -r ".[] | [.cycle, .latest, (.eol | tostring)] | @tsv" /tmp/eol-nodejs.jsonLangkah lanjutan yang biasa dipakai di proyek nyata: simpan versi runtime di satu file (misalnya hasil node --version, python3 --version, psql --version dari host produksi), lalu bandingkan major-nya dengan daftar siklus. Kalau tidak ada yang cocok dengan siklus yang masih bertanggal masa depan, output-nya satu baris peringatan. Tidak perlu dashboard untuk tahu bahwa sebuah sistem berjalan di rilis yang sudah lewat tenggat.
Versi mana yang layak dipasang untuk proyek baru
Untuk instalasi baru, pertanyaannya bukan "versi terbaru apa", tapi "berapa lama proyek ini harus hidup". Aturan praktisnya bisa diturunkan langsung dari JSON yang sama. Pada Node.js, siklus bernomor genap yang punya tanggal LTS adalah kandidat default, dan hari ini ada dua: 24 dengan support sampai 2026-10-20 dan 26 yang baru mulai LTS pada 2026-10-28. Untuk proyek yang baru mulai September 2026 dan ditargetkan jalan tiga tahun, memilih 24 berarti menjadwalkan upgrade sebelum akhir Oktober, sementara menunggu beberapa minggu lagi membuat 26 jadi pilihan yang lebih panjang umurnya.
Python punya kekhasan yang terlihat di data yang sama: tidak ada siklus yang bertanda LTS. Semua cycle bernilai lts: false, dan yang membedakan cuma kombinasi support serta eol. Karena itu strategi versioning Python biasanya mengikuti jadwal rilis bahasa, bukan label komersial, dan pilihan aman untuk proyek panjang adalah siklus dengan tanggal support paling jauh yang sudah benar-benar stabil di ekosistem dependency lo.
Ubuntu memberi contoh lain: 26.04 LTS dengan EOL 2031-05-29, jauh di depan 25.10 yang tercatat sudah lewat pada 2026-07-01. Untuk server yang jarang direinstal, selisih lima tahun itu nyata, dan memasang rilis non-LTS hanya beralasan kalau ada kebutuhan perangkat keras atau kernel tertentu.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬