Siklus hidup versi
MediaWiki beroperasi dalam model pengembangan "integrasi berlanjut", di mana perubahan perangkat lunak didorong langsung ke situs web Wikimedia seperti Wikipedia secara rutin.
Dalam teorinya, rilis utama yang baru diterbitkan setiap setengah tahun, dan rilis cabang terus mendapatkan pembaruan keamanan selama setahun sejak rilis pertamanya. Karena batasan waktu dan refaktorisasi basis kode yang cepat, kami tidak bisa mendukung rilis yang lama selamanya, dan pembaruan keamanan dan pembaruan kritis tidak diterapkan pada rilis yang telah mencapai status ujung hidupnya.
Pengelola rilis sangat merekomendasikan kepada operator wiki untuk berlangganan dengan milis mediawiki-announce, yang menerima pemberitahuan mengenai semua rilis, dan memastikan wiki mereka menjalankan versi perangkat lunak yang paling terkini. Pengumuman-pengumuman ini juga dipos di mediawiki-l dan wikitech-l.
Versi dan akhir hidupnya
| Versi | Status | Rilis | Akhir hidup |
|---|---|---|---|
| 1.44.x | versi mendatang | ||
| 1.43.x (LTS) | versi dukungan-jangka-panjang mendatang | ||
| 1.42.x | versi stabil saat ini | ||
| 1.41.x | versi warisan | ||
| 1.40.x | versi usang | ||
| 1.39.x (LTS) | versi dukungan-jangka-panjang saat ini | ||
| 1.38.x | versi usang |
Versi-versi yang disebutkan dalam tabel di atas yang ditandai sebagai usang serta versi-versi yang sama sekali tidak disebutkan tidak akan mendapatkan perbaikan keamanan. Mereka mungkin mengandung kelemahan keamanan yang kritis dan kekutu-kekutu besar lainnya, termasuk ancaman kehilangan dan/atau rusaknya data. Pengelola rilis mengeluarkan rekomendasi tegas bahwa hanya versi di atas yang ditandai sebagai "versi stabil", "versi warisan", atau "versi dukungan jangka panjang" saat ini saja yang digunakan di lingkungan produksi. This also includes all versions older than the oldest version listed. They may contain critical security vulnerabilities and other major bugs, including the threat of possible data loss and/or corruption. The release manager has also issued a strong recommendation that only versions listed above as the current “stable version”, "legacy version" or “long-term support version” be used in a production environment.
- Alpha development
- Release development
- Stable release
- Long-term support release
Kebijakan perilisan
- Setiap rilis titik akan berisi berkas i18n yang diperbarui serta perbaikan kekutu manapun. Tidak ada fitur baru yang akan di-backport ke rilis titik dan dukungan tidak selalu termasuk untuk ekstensi dan kulit yang sepaket secara umum.
- Rilis utama akan dilakukan setiap enam bulan.
- A minor release (including security patches, message translation back-ports, and general bugfixes) will be made every quarter.
- Rilis dukungan jangka panjang (bahasa Inggris: long term support, disingkat LTS) akan dilakukan setiap dua tahun. Akan terdapat satu tahun di mana dua versi LTS didukung. Contohnya, 1.23 didukung hingga Mei 2017. 1.27 dirilis pada tahun sebelumnya, jadi, orang-orang akan memiliki LTS untuk dijadikan tujuan pindah dan satu tahun untuk melakukan perpindahannya.
- Catatan perilisan akan terus menjadi dasar untuk melihat apa yang telah diubah. Dikarenakan sifat dari proyek yang didorong oleh sukarelawan, tidak mungkin mengatakan dengan pasti mengenai apa yang akan terjadi pada 6—12 bulan ke depan.
Jadwal rilis
Garis waktu ini adalah jadwal mengenai apa yang harus dilakukan sebelum perilisan versi baru. Tanggal perilisan di sini dilambangkan dengan T (kependekan dari "time"/"waktu" perilisan) dan akhiran -# (melambangkan "banyak pekan sebelum perilisan").
| Jadwal relatif | Tugas |
|---|---|
| T - 7 | Umumkan bahwa rilis cabang akan dibuat dalam satu pekan. Tanyakan orang-orang untuk memastikan segala hal yang diperlukan untuk menyelesaikan fitur yang belum selesai telah digabungkan sebelumnya. Buat "MW-X.XX-release" di Phabricator. |
| T - 6 | Buat cabang untuk inti dan semua ekstensi di Gerrit. |
| T - 5 | Terapkan tag X.XX-rc.0 dan rilis kandidat rilis awal. |
| T - 4 | Kumpulkan semua laporan kekutu dan kirimkan ringkasannya di milis. |
| T - 3 | Terapkan flag X.XX-rc.1 dan rilis kandidat rilis kedua. Semua ekstensi baru yang diusulkan untuk ditambahkan ke tarball sebaiknya sudah dimasukkan ke dalamnya. Tidak ada perubahan ekstensi lagi setelah ini. |
| T - 2 | Kumpulkan semua laporan kekutu baru, gabungkan semua perbaikan, keluarkan fitur baru yang belum lengkap dan tidak sengaja dimasukkan, terapkan tag X.XX-rc.2 dan rilis kandidat rilis ketiga. |
| T - 1 | Ulangi tahap sebelumnya, gunakan X.XX-rc.final sebagai tag dan rilis. Tidak ada backport yang diterima setelah ini. |
| T | Tandai repositori sebagai X.XX dan buat rilisnya. |
Pengelolaan siklus hidup ekstensi
Kebanyakan pemasangan MediaWiki mengandung banyak sekali ekstensi (wiki Wikimedia biasanya mengadung sekitar 140). Mengelola perbaikan kekutu pemeliharaan ekstensi dan memilih versi yang benar dari ekstensi dalam kasus di mana versi pengembangan HEAD bergantung pada fitur yang belum tersedia di inti MediaWiki versi stabil atau oldstable, bisa jadi sulit. Managing the maintenance bug fixing of extensions and choosing the right version of an extension in cases where the HEAD development version relies on features not yet available in stable or oldstable MediaWiki core can be challenging.
Oleh karena itu, pemelihara ekstensi sangat disarankan untuk mengelola cabang git untuk setiap versi ekstensi sesuai dengan versi MediaWikinya.
(Lihat Kompatibilitas#Ekstensi MediaWiki untuk rinciannya.)
Untuk ekstensi yang dihos di repositori git Wikimedia, cabang seperti itu (dengan nama seperti REL1_30 untuk MediaWiki 1.30) dibuat secara otomatis dari master ketika versi MediaWiki baru dicabangkan (dengan asumsi bahwa master ekstensinya selalu cocok dengan master MediaWiki).
Namun, lebih baik apabila pemelihara ekstensi memperbaiki kekutu tidak hanya di HEAD tapi juga di versi stabil dan oldstable (dengan mem-backport perbaikan ke cabang lama apabila perlu).
Tujuan dari aturan-aturan ini adalah agar orang-orang atau organisasi yang memasang MediaWiki bisa mengandalkan pemasangan versi rilis terbaru dan ekstensi yang sesuai dengan cara yang sederhana, contohnya untuk inti 1.20.x dengan mengacu pada REL1_20 di git.
Dan ini menghindari berkas tarball dan zip dengan nama yang tidak relevan dan sulit ditebak.
Lihat pula
- Compatibility information for MediaWiki, most importantly PHP and MySQL
- Kebijakan antarmuka stabil
- Generator di WikiApiary — Statistik mengenai penggunaan versi MediaWiki yang berbeda-beda.