Python 3.10 EOL 1 Oktober 2026: Cara Aman Upgrade python3 di Linux

Python 3.10 resmi berakhir dukungannya pada 1 Oktober 2026, dan rilis terakhirnya adalah 3.10.22 di tanggal yang sama. Di sisi lain, Python 3.15 sudah tersedia sejak 9 Oktober 2026 dan pada 25 Oktober 2026 sudah mencapai 3.15.2, sementara 3.14 berada di 3.14.10. Server Linux yang masih memakai python3 dari jalur 3.10 sekarang berjalan tanpa patch keamanan dari tim CPython.

Sampai kapan tiap versi Python masih didukung?

Python 3.10 berakhir 1 Oktober 2026, 3.11 berakhir 31 Oktober 2027, 3.12 berakhir 31 Oktober 2028, 3.13 berakhir 31 Oktober 2029, 3.14 berakhir 31 Oktober 2030, dan 3.15 berakhir 31 Oktober 2031. Pola lima tahun per versi konsisten selama beberapa rilis terakhir.

Yang sering disalahpahami adalah dua fase di dalam lima tahun itu. Fase pertama adalah bugfix, biasanya sekitar dua tahun, di mana perbaikan bug dan keamanan sama-sama masuk. Fase kedua adalah security only, sekitar tiga tahun, di mana hanya perbaikan keamanan yang diterima.

Versi	Rilis pertama	Akhir fase bugfix	Akhir dukungan	Rilis terbaru
3.10	4 Oktober 2021	1 April 2023	1 Oktober 2026	3.10.22
3.11	24 Oktober 2022	1 April 2024	31 Oktober 2027	3.11.18
3.12	2 Oktober 2023	2 April 2025	31 Oktober 2028	3.12.16
3.13	7 Oktober 2024	1 Oktober 2026	31 Oktober 2029	3.13.18
3.14	7 Oktober 2025	1 Oktober 2027	31 Oktober 2030	3.14.10
3.15	9 Oktober 2026	9 Oktober 2028	31 Oktober 2031	3.15.2

Kolom akhir fase bugfix menjelaskan sesuatu yang sering mengejutkan: 3.13 baru saja keluar dari fase bugfix pada 1 Oktober 2026, padahal versi itu masih terasa baru. Sesudah titik itu, bug non-keamanan yang ditemukan di 3.13 tidak akan diperbaiki lagi.

Apakah aman menimpa python3 bawaan sistem?

Tidak. Interpreter python3 bawaan distribusi dipakai oleh perkakas sistem, termasuk manajer paket, skrip instalasi, dan utilitas administrasi. Menimpanya dengan versi lain membuat perkakas itu berisiko berhenti bekerja, dan kerusakannya sering baru terasa saat sistem sedang bermasalah, misalnya ketika manajer paket gagal dijalankan tepat saat dibutuhkan.

Pendekatan yang benar adalah membiarkan interpreter sistem apa adanya, lalu memasang versi baru berdampingan. Di banyak distribusi, itu berarti memasang paket python3 versi baru dengan nama perintah yang berbeda, atau memakai manajer versi seperti pyenv untuk keperluan pengembangan.

Untuk menjalankan aplikasi, venv tetap jawaban paling sederhana, karena interpreter sistem tidak perlu diubah sama sekali dan setiap aplikasi bisa punya dependensi berbeda. Satu direktori venv per aplikasi membuat dependensi tidak saling bertabrakan, interpreter yang dipakai bisa dipilih saat venv dibuat, dan menghapus venv lama adalah rollback yang bersih tanpa menyentuh sistem. Ketika aplikasi perlu pindah ke versi Python baru, cukup buat venv baru dan pasang ulang dependensi.

Kenapa pip menolak instalasi ke interpreter sistem?

Karena interpreter itu ditandai sebagai externally managed mengikuti PEP 668. Penanda ini membuat pip berhenti sebelum menulis paket ke direktori sistem, dengan pesan yang menyebut istilah externally-managed-environment. Tujuannya mencegah paket hasil pip bertabrakan dengan paket yang dikelola manajer paket distro.

Penolakan itu bukan bug, dan memaksa lewat flag pengabaian bukan solusi. Kalau sebuah perintah instalasi disarankan memakai flag khusus untuk menembus penanda tersebut, tanda paling jelas bahwa pekerjaan itu seharusnya dilakukan di dalam venv, bukan di interpreter sistem.

Alurnya sederhana: buat venv dengan interpreter yang diinginkan, aktifkan, lalu pasang paket di sana. Satu venv per aplikasi lebih aman daripada satu venv untuk semua, karena dependensi antarproyek jarang sepakat satu sama lain. Untuk service yang berjalan otomatis, venv cukup dipanggil lewat jalur absolut, sehingga tidak perlu aktivasi manual. Yang penting adalah jalur interpreter di unit service menunjuk ke venv, bukan ke python3 sistem.

Bagaimana memeriksa versi Python yang benar-benar dipakai service?

Jalankan python3 --version di dalam konteks service, bukan di shell biasa. Perbedaan hasil antara keduanya adalah sumber kebingungan paling umum, karena service sering memakai jalur interpreter yang berbeda dari yang dipakai saat login.

1. Cek versi global: python3 --version dan which -a python3 untuk melihat semua jalur yang tersedia.
2. Cek versi di dalam venv: jalankan interpreter venv secara langsung, misalnya lewat jalur absolut ke bin/python di direktori venv.
3. Cek unit service: lihat baris ExecStart dan pastikan jalurnya menunjuk interpreter yang diharapkan, bukan interpreter sistem.
4. Cek sistem prefix dari dalam proses: cetak sys.prefix dan sys.executable dari aplikasi yang berjalan, karena keduanya menunjukkan lingkungan yang benar-benar dipakai.
5. Catat hasilnya di dokumentasi internal, supaya pemeriksaan berikutnya punya pembanding.

Langkah keempat adalah yang paling meyakinkan. Output python3 --version di shell memberi tahu versi yang dipakai shell, sementara sys.executable dari dalam aplikasi memberi tahu versi dan lingkungan yang benar-benar menjalankan kode produksi.

Bagaimana memindahkan aplikasi dari 3.10 ke versi yang didukung?

Pindahkan per aplikasi, bukan per server, dan uji di salinan sebelum menyentuh produksi. Pendekatan per server cenderung memaksa satu versi untuk semua aplikasi, dan itu justru membuat upgrade berikutnya sama sulitnya.

1. Daftar semua aplikasi beserta versi Python yang dipakai sekarang, termasuk cron job dan skrip sekali jalan.
2. Untuk tiap aplikasi, buat venv baru dengan interpreter tujuan, lalu pasang dependensi dari lockfile atau requirements yang sama.
3. Jalankan test aplikasi di venv baru. Perhatikan peringatan deprecation, karena itu penanda perubahan yang akan datang.
4. Periksa paket native yang butuh kompilasi, karena paket seperti itu biasanya perlu wheel yang cocok untuk versi interpreter baru.
5. Setelah lolos, ubah jalur interpreter di unit service atau skrip start, lalu restart dan periksa log.
6. Simpan venv lama sampai aplikasi stabil, lalu hapus setelah yakin tidak ada rollback.

Poin keempat adalah tempat paling sering muncul kegagalan yang tidak terlihat di mesin pengembangan. Paket yang bergantung pada pustaka C atau header sistem bisa gagal dibangun di server tanpa paket pengembangan yang sesuai, dan kegagalannya baru muncul saat pemasangan, bukan saat test.

Untuk skrip yang dijalankan cron, jangan lupa memeriksa shebang dan jalur interpreter di crontab. Skrip yang memanggil python3 lewat PATH akan memakai interpreter sistem, bukan venv, meskipun venv sudah dibuat dengan benar.

Versi mana yang sebaiknya dipilih untuk produksi sekarang?

Python 3.12 atau 3.13 adalah pilihan paling seimbang per akhir Oktober 2026, karena keduanya masih jauh dari akhir dukungan, masing-masing sampai 2028 dan 2029, dan sudah cukup lama dipakai di ekosistem sehingga hampir semua paket menyediakan wheel siap pasang. Python 3.15 yang rilis 9 Oktober 2026 sebaiknya dipakai untuk pengujian lebih dulu, bukan langsung untuk seluruh produksi.

Alasannya soal ekosistem, bukan kualitas rilis. Rilis baru selalu butuh waktu sampai paket populer menyediakan wheel untuknya, dan paket yang belum menyediakan wheel memaksa kompilasi dari sumber. Untuk server kecil tanpa compiler dan header lengkap, itu berarti pemasangan gagal.

Kalau ada kebutuhan untuk mengikuti rilis terbaru, pola yang aman adalah dua jalur: produksi di versi yang sudah matang, dan satu lingkungan uji di versi terbaru. Biaya menyiapkan lingkungan uji jauh lebih kecil dibanding kejutan pemasangan paket di jam sibuk. Dengan begitu, upgrade berikutnya tidak dimulai dari nol ketika versi lama mendekati akhir dukungan.

Venv, pyenv, atau paket distro: mana yang sebaiknya dipakai?

Pakai paket distro untuk perkakas sistem, venv untuk dependensi aplikasi, dan pyenv hanya kalau satu mesin harus menampung beberapa versi Python untuk pengembangan. Ketiganya bukan pilihan yang saling menggantikan, melainkan lapisan berbeda dalam satu server.

Pendekatan	Cocok untuk	Efek pada interpreter sistem	Risiko utama
Paket distro	Perkakas sistem dan utilitas yang dipanggil root	Tidak berubah, mengikuti repositori distro	Versi tertinggal dari rilis CPython
venv	Dependensi tiap aplikasi	Tidak berubah	Harus diingat di cron dan unit service
pyenv	Beberapa versi untuk pengembangan	Tidak berubah, tapi PATH bisa tertimpa	Mudah salah versi di shell berbeda

Kombinasi yang paling sedikit mengejutkan: interpreter dasar dari distro atau dari paket resmi, venv per aplikasi, dan pyenv hanya di akun pengguna untuk eksperimen. Dengan susunan ini, upgrade versi Python tidak pernah mengubah apa pun yang dipakai sistem, dan rollback cukup dengan mengarahkan unit service kembali ke venv lama.

Yang perlu diwaspadai dari pyenv adalah efek pada PATH. Karena shim-nya mengubah perintah python3 di shell, versi yang dipakai bisa berbeda antara shell interaktif, cron, dan unit service. Kalau pyenv dipakai, jalur absolut ke interpreter lebih aman daripada mengandalkan nama perintah.

FAQ

Apakah Python 3.10 langsung berhenti bekerja pada 1 Oktober 2026?

Tidak. Interpreter tetap berjalan normal, tetapi tidak lagi menerima patch keamanan dari tim CPython. Rilis terakhir jalur itu adalah 3.10.22 pada 1 Oktober 2026, dan tidak ada rilis berikutnya.

Bisakah memasang paket pip di python3 sistem dengan flag paksa?

Secara teknis bisa, tetapi berisiko menimpa paket yang dikelola manajer paket distro. Cara yang dianjurkan PEP 668 adalah membuat venv, sehingga dependensi aplikasi terpisah dari paket sistem.

Apakah Python 3.15 sudah layak untuk produksi?

Bisa dipakai, tetapi lebih aman diuji lebih dulu. Python 3.15 dirilis 9 Oktober 2026 dan sudah mencapai 3.15.2 pada 25 Oktober 2026, jadi perbaikan awal sudah masuk, meski dukungan paket pihak ketiga masih menyesuaikan.

Di mana rilis terbaru tiap versi bisa dicek?

Di halaman unduhan resmi Python, misalnya rilis 3.15.2 dan rilis penutup 3.10.22, serta jadwal dukungan di PEP 790 untuk Python 3.15.