ReleasePlan/id

Pengantar
Berlatih melakukan rilis berbasis waktu telah terbukti menghasilkan perangkat lunak bebas kualitas terbaik. Rilis berbasis waktu adalah rilis yang tidak menunggu fitur, atau perbaikan kutu - tetapi didasarkan (semurni mungkin) pada ketepatan waktu. Hal ini membantu menerapkan disiplin dalam memperkenalkan perbaikan, memberikan perkiraan, dan memungkinkan rilis yang lebih teratur. Hal ini juga merupakan keadaan di mana kita harus melakukan rilis lebih awal, dan kemudian dengan cepat melakukan rilis perbaikan kutu berdasarkan versi stabil sebelumnya. Jadi, jika Anda membutuhkan versi kualitas tertinggi, masuk akal untuk menunda langkah hingga rilis poin minor pertama atau mungkin kedua.


 * LibreOffice melakukan rilis dua tahun sekali yang dapat diperkirakan dan selaras dengan proyek Perangkat Lunak Bebas lainnya (misalnya Gnome) dan setidaknya satu bulan ke depan rilis distribusi Linux utama.


 * Menyinkronkan jadwal rilis berbasis waktu dengan ekosistem Perangkat Lunak Bebas yang lebih luas juga memiliki keuntungan besar: yaitu dengan mendapatkan fitur baru secepat mungkin ke pengguna - dengan kelambatan minimal siklus distribusi. Sebagai akibatnya, kami menargetkan enam rilis bulanan, dan seiring waktu mendorong mereka agar selaras dengan norma Maret/September.


 * Berlatih melakukan rilis berbasis waktu telah terbukti menghasilkan perangkat lunak merdeka kualitas terbaik. Rilis berbasis waktu adalah rilis yang tidak menunggu fitur, atau perbaikan kutu - tetapi didasarkan (semurni mungkin) pada ketepatan waktu. Hal ini membantu menerapkan disiplin dalam memperkenalkan perbaikan, memberikan perkiraan, dan memungkinkan rilis yang lebih teratur.  Hal ini juga merupakan keadaan di mana kita harus melakukan rilis lebih awal, dan kemudian dengan cepat melakukan rilis perbaikan kutu berdasarkan versi stabil sebelumnya. Jadi, jika Anda membutuhkan versi kualitas tertinggi, masuk akal untuk menunda langkah hingga rilis poin minor pertama atau mungkin kedua.


 * Terdapat dua cabang: Fresh (rilis terbaru) dan Still (rilis sebelumnya), yang masing-masing ditujukan untuk pengguna fitur utama dan deployment perusahaan konservatif.


 * Sebagai hasilnya, pengguna mendapatkan versi utama baru setiap enam bulan dengan berbagai fitur, perbaikan, dan peningkatan. Selain itu, mereka mendapatkan banyak rilis mikro murni perbaikan kutu. Rilis X.Y.0 pertama ditujukan untuk pengguna awal. Pengguna yang lebih konservatif disarankan untuk menunggu rilis perbaikan kutu X.Y.Z nanti.

Perhatikan bahwa tanggal yang disebutkan dalam jadwal mungkin bergeser jika ada masalah teknis atau masalah serius lainnya dengan rilis. Kandidat rilis tambahan mungkin diperlukan jika kandidat rilis final tidak sesuai dengan Kriteria Rilis. Masalah seperti itu akan menggeser rilis final satu pekan atau lebih.

The simplified graphic below shows three releases placed on a timeline consisting of 24 months.

Future Fresh Still

7.4 release
See also the detailed schedule and the release notes.

7.3 release
See also the detailed schedule and the release notes.

7.2 release
See also the detailed schedule and the release notes.

7.1 release
See also the detailed schedule and the release notes.

Rilis 7.0
Lihat juga jadwal terperinci dan catatan rilis.

Rilis 6.4
Lihat juga jadwal terperinci dan catatan rilis.

Rilis 6.3
Lihat juga jadwal terperinci dan catatan rilis.

Tanggal
Rilis dilakukan berdasarkan waktu tetapi jadwal menentukan pekan, bukan tanggal tertentu. Hal ini dikarenakan kita selalu sedikit luwes. Rilis ini dapat ditunda beberapa hari karena kutu pemblokir, masalah build, dan masalah teknis lainnya.

Rilis ini terdiri dari beberapa versi beta dan kandidat rilis. Diperlukan beberapa tindakan untuk setiap build. Alur kerja ideal tampak seperti berikut ini:


 * Senin: tenggat waktu commit; pengingat dikirim ke milis pengembang dan pelokalan sebelum tenggat terjadi
 * Selasa: tag dibuat pada commit yang mem-build dan lulus pengujian unit, pengujian subsequent, dan pengujian smoke; tag diumumkan pada milis pengembang dan qa
 * Rabu: build diunggah di situs pra-rilis awal; kemudian diumumkan di milis pengembang dan jaminan mutu
 * Kamis: build diunggah ke mirror. Lalu diumumkan melalui banyak saluran, misalnya milis, twitter
 * Jumat: versi tersedia melalui situs pra-rilis resmi

Rilis final biasanya diumumkan pada hari Kamis, beberapa hari setelah kandidat rilis final keluar.

Perhatikan bahwa kami sangat ketat tentang komitmen terhadap kandidat rilis final, sehingga uji regresi penuh tidak diperlukan. Hal ini digunakan sebagai build akhir ketika melewati pengujian yang dibutuhkan sehingga hanya diganti namanya di mirror.

Jadwal
Jadwal didasarkan pada aturan berikut:


 * lakukan rilis utama setiap enam bulan dan sinkronkan (setidaknya satu bulan ke depan) dengan distribusi Linux utama; rilis ini selalu disertai dengan berbagai fitur, perbaikan, dan peningkatan
 * lakukan rilis perbaikan kutu murni setiap bulan setelah rilis utama sampai cukup baik bahkan untuk orang yang paling konservatif; lakukan lebih jarang setelah itu
 * lakukan rilis perbaikan kutu murni, termasuk perbaikan keamanan, sampai rilis berikutnya siap untuk kebanyakan orang konservatif
 * jangan lakukan dua build di pekan yang sama.

Hasilnya adalah templat berikut:

Di mana (w) berarti awal bulan, (t) berarti pertengahan bulan dan (k) berarti akhir bulan.

Pembekuan string
Rencana rilis untuk versi pertama dari setiap rilis utama menunjukkan "pembekuan string bahasa Inggris & antarmuka yang keras". Idenya adalah untuk membuat kehidupan penerjemah lebih mudah. Para penerjemah harus dapat mempercayai bahwa tidak ada string terjemahan yang baru ditambahkan ke dalam antarmuka atau berkas Bantuan antara periode pembekuan dan pelepasan string.

Setelah versi pertama rilis utama keluar, memperbaiki kesalahan string pada antarmuka dan Bantuan bisa dilakukan. Konten yang benar-benar baru harus ditargetkan pada rilis besar berikutnya.

Skema versi
Kami melakukan beberapa build di sekitar setiap rilis. Skema versi berikut digunakan:


 * X.Y.0.0.alphaZ - Zth versi alpha dari rilis awal
 * X.Y.0.0.betaZ - Zth versi beta dari rilis awal
 * X.Y.0.Z - Calon rilis ke-Z dari rilis awal, kandidat rilis terakhir dianggap sebagai final dan diletakkan di halaman unduhan utama
 * X.Y.1.Z - Calon rilis ke-Z dari rilis perbaikan kutu pertama, kandidat rilis terakhir dianggap sebagai final dan diletakkan di halaman unduhan utama

Kesemuanya ini menjadi kompromi terbaik dengan keuntungan-keuntungan sebagai berikut:


 * mudah dimengerti oleh pengguna normal. Bendera alpha, beta diketahui dari proyek lain, sehingga ada harapan yang bisa dipahami
 * pengurutan alfabet yang benar dalam RPM, Bugzilla
 * "Mudah" untuk diurai (string alpha/beta dibatasi oleh titik)

Terdapat diskusi panjang tentang skema ini di milis.

Mempercepat siklus rilis
Akselerasi siklus rilis ini melibatkan beberapa teknik rilis dan upaya JM yang cukup besar. Untuk mengurangi biaya ini, kami berupaya menyediakan snapshot harian lengkap (misalnya yang berisi semua bahasa) dari cabang master untuk memungkinkan pengujian berkelanjutan terhadap peningkatan kode. Hal ini sudah berfungsi sebagian, seperti yang dapat dilihat/diunduh dari sini.

Demikian pula, kami berencana untuk semakin mengotomatiskan proses build agar memungkinkan aliran rilis dengan sentuhan lebih sedikit, juga untuk terus mengecilkan jejak biner kami untuk memungkinkan transfer build yang jauh lebih cepat setara dengan produk.

Rilis Akhir-Hayat
Rilis biasanya memiliki masa hidup sekitar sembilan bulan. Kami menganggap rilis telah mencapai Akhir Hayat/End of Life (EOL) satu bulan setelah rilis yang direncanakan terakhir.

Jika Anda ingin dukungan jangka panjang untuk rilis, Anda dianjurkan untuk menggunakan penyedia L3 bersertifikat yang dapat memberi Anda layanan ini.

Dikarenakan jumlah data, rilis dibagi menjadi ReleasePlan/Arsip.