RencanaRilis

From The Document Foundation Wiki
Jump to: navigation, search
This page is a translated version of the page ReleasePlan and the translation is 100% complete.

Other languages:
العربية • ‎dansk • ‎Deutsch • ‎English • ‎español • ‎français • ‎Bahasa Indonesia • ‎italiano • ‎日本語 • ‎português do Brasil • ‎română • ‎русский • ‎中文(简体)‎

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.

Rilis 7.0

Tanggal dasar untuk rilis awal dan perbaikan kutu
Rilis Pembekuan Publikasi
7.0.0 (pembekuan: pekan ke-29) Pekan 19 , 4 Mei 2020 - 10 Mei 2020 Pekan 32 , 3 Agustus 2020 - 9 Agustus 2020
7.0.1 Pekan 33 , 10 Agustus 2020 - 16 Agustus 2020 Pekan 36 , 31 Agustus 2020 - 6 September 2020
7.0.2 Pekan 38 , 14 September 2020 - 20 September 2020 Pekan 41 , 5 Oktober 2020 - 11 Oktober 2020
7.0.3 Pekan 43 , 19 Oktober 2020 - 25 Oktober 2020 Pekan 46 , 9 November 2020 - 15 November 2020
7.0.4 Pekan 48 , 23 November 2020 - 29 November 2020 Pekan 51 , 14 Desember 2020 - 20 Desember 2020
7.0.5 Pekan 06 , 8 Februari 2021 - 14 Februari 2021 Pekan 09 , 1 Maret 2021 - 7 Maret 2021
7.0.6 Pekan 15 , 12 April 2021 - 18 April 2021 Pekan 18 , 3 Mei 2021 - 9 Mei 2021
Akhir Hayat 31 Mei 2021

Lihat juga jadwal terperinci dan catatan rilis.

Rilis 6.4

Tanggal dasar untuk rilis awal dan perbaikan kutu
Rilis Pembekuan Publikasi
6.4.0 (pembekuan: pekan ke-2) Pekan 42 , 14 Oktober 2019 - 20 Oktober 2019 Pekan 05 , 27 Januari 2020 - 2 Februari 2020
6.4.1 Pekan 06 , 3 Februari 2020 - 9 Februari 2020 Pekan 09 , 24 Februari 2020 - 1 Maret 2020
6.4.2 Pekan 09 , 24 Februari 2020 - 1 Maret 2020 Pekan 12 , 16 Maret 2020 - 22 Maret 2020
6.4.3 Pekan 13 , 23 Maret 2020 - 29 Maret 2020 Pekan 16 , 13 April 2020 - 19 April 2020
6.4.4 Pekan 18 , 27 April 2020 - 3 Mei 2020 Pekan 21 , 18 Mei 2020 - 24 Mei 2020
6.4.5 Pekan 24 , 8 Juni 2020 - 14 Juni 2020 Pekan 27 , 29 Juni 2020 - 5 Juli 2020
6.4.6 Pekan 30 , 20 Juli 2020 - 26 Juli 2020 Pekan 33 , 10 Agustus 2020 - 16 Agustus 2020
6.4.7 Pekan 39 , 21 September 2020 - 27 September 2020 Pekan 42 , 12 Oktober 2020 - 18 Oktober 2020
Akhir Hayat 30 November 2020

Lihat juga jadwal terperinci dan catatan rilis.

Rilis 6.3

Tanggal dasar untuk rilis awal dan perbaikan kutu
Rilis Pembekuan Publikasi
6.3.0 (pembekuan: pekan ke-29) Pekan 19 , 6 Mei 2019 - 12 Mei 2019 Pekan 32 , 5 Agustus 2019 - 11 Agustus 2019
6.3.1 Pekan 32 , 5 Agustus 2019 - 11 Agustus 2019 Pekan 35 , 26 Agustus 2019 - 1 September 2019
6.3.2 Pekan 36 , 2 September 2019 - 8 September 2019 Pekan 39 , 23 September 2019 - 29 September 2019
6.3.3 Pekan 41 , 7 Oktober 2019 - 13 Oktober 2019 Pekan 44 , 28 Oktober 2019 - 3 November 2019
6.3.4 Pekan 47 , 18 November 2019 - 24 November 2019 Pekan 50 , 9 Desember 2019 - 15 Desember 2019
6.3.5 Pekan 05 , 27 Januari 2020 - 2 Februari 2020 Pekan 08 , 17 Februari 2020 - 23 Februari 2020
6.3.6 Pekan 15 , 6 April 2020 - 12 April 2020 Pekan 18 , 27 April 2020 - 3 Mei 2020
Akhir Hayat 29 Mei 2020

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:

Rilis yang saling terkait
Kegiatan Musim panas Musim dingin
x.y Pembekuan fitur Jun(w) Des(w)
x.y.0 Rilis pertama Ags(w) Feb(w)
x.y.1 Rilis perbaikan kutu Sep(w) Mar(w)
x.y.2 Rilis perbaikan kutu Okt(w) Apr(w)
x.y.3 Rilis perbaikan kutu Nov(w) Mei(w)
x.y.4 rilis perbaikan kutu Des(w) Jun(w)
x.y.5 rilis perbaikan kutu Feb(t) Ags(t)
x.y.6 rilis perbaikan kutu Apr(t) Okt(t)

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.