RencanaRilis

    From The Document Foundation Wiki
    This page is a translated version of the page ReleasePlan and the translation is 62% complete.
    Outdated translations are marked like this.

    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.
    • 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

    24.2 release

    Basic dates for the initial and bugfix releases
    Release Freeze Publishing
    24.2.0 (freeze: week 02) Pekan 47 , 20 November 2023 - 26 November 2023 Pekan 05 , 29 Januari 2024 - 4 Februari 2024
    24.2.1 Pekan 06 , 5 Februari 2024 - 11 Februari 2024 Pekan 09 , 26 Februari 2024 - 3 Maret 2024
    24.2.2 Pekan 10 , 4 Maret 2024 - 10 Maret 2024 Pekan 13 , 25 Maret 2024 - 31 Maret 2024
    24.2.3 Pekan 15 , 8 April 2024 - 14 April 2024 Pekan 18 , 29 April 2024 - 5 Mei 2024
    24.2.4 Pekan 20 , 13 Mei 2024 - 19 Mei 2024 Pekan 23 , 3 Juni 2024 - 9 Juni 2024
    24.2.5 Pekan 26 , 24 Juni 2024 - 30 Juni 2024 Pekan 29 , 15 Juli 2024 - 21 Juli 2024
    24.2.6 Pekan 33 , 12 Agustus 2024 - 18 Agustus 2024 Pekan 36 , 2 September 2024 - 8 September 2024
    24.2.7 Pekan 41 , 7 Oktober 2024 - 13 Oktober 2024 Pekan 44 , 28 Oktober 2024 - 3 November 2024
    End of Life November 30, 2024

    See also the detailed schedule and the release notes.

    7.6 release

    Basic dates for the initial and bugfix releases
    Release Freeze Publishing
    7.6.0 (freeze: week 30) Pekan 19 , 8 Mei 2023 - 14 Mei 2023 Pekan 34 , 21 Agustus 2023 - 27 Agustus 2023
    7.6.1 Pekan 34 , 21 Agustus 2023 - 27 Agustus 2023 Pekan 37 , 11 September 2023 - 17 September 2023
    7.6.2 Pekan 38 , 18 September 2023 - 24 September 2023 Pekan 39 , 25 September 2023 - 1 Oktober 2023
    7.6.3 Pekan 44 , 30 Oktober 2023 - 5 November 2023 Pekan 47 , 20 November 2023 - 26 November 2023
    7.6.4 Pekan 50 , 11 Desember 2023 - 17 Desember 2023 Pekan 53 , 1 Januari 2024 - 7 Januari 2024
    7.6.5 Pekan 05 , 29 Januari 2024 - 4 Februari 2024 Pekan 08 , 19 Februari 2024 - 25 Februari 2024
    7.6.6 Pekan 10 , 4 Maret 2024 - 10 Maret 2024 Pekan 13 , 25 Maret 2024 - 31 Maret 2024
    7.6.7 Pekan 16 , 15 April 2024 - 21 April 2024 Pekan 19 , 6 Mei 2024 - 12 Mei 2024
    End of Life June 12, 2024

    See also the detailed schedule and the release notes.


    7.5 release

    Basic dates for the initial and bugfix releases
    Release Freeze Publishing
    7.5.0 (freeze: week 02) Pekan 47 , 21 November 2022 - 27 November 2022 Pekan 05 , 30 Januari 2023 - 5 Februari 2023
    7.5.1 Pekan 06 , 6 Februari 2023 - 12 Februari 2023 Pekan 09 , 27 Februari 2023 - 5 Maret 2023
    7.5.2 Pekan 10 , 6 Maret 2023 - 12 Maret 2023 Pekan 13 , 27 Maret 2023 - 2 April 2023
    7.5.3 Pekan 15 , 10 April 2023 - 16 April 2023 Pekan 18 , 1 Mei 2023 - 7 Mei 2023
    7.5.4 Pekan 20 , 15 Mei 2023 - 21 Mei 2023 Pekan 23 , 5 Juni 2023 - 11 Juni 2023
    7.5.5 Pekan 26 , 26 Juni 2023 - 2 Juli 2023 Pekan 29 , 17 Juli 2023 - 23 Juli 2023
    7.5.6 Pekan 33 , 14 Agustus 2023 - 20 Agustus 2023 Pekan 36 , 4 September 2023 - 10 September 2023
    7.5.7 Pekan 38 , 18 September 2023 - 24 September 2023 Pekan 39 , 25 September 2023 - 1 Oktober 2023
    7.5.8 Pekan 41 , 9 Oktober 2023 - 15 Oktober 2023 Pekan 44 , 30 Oktober 2023 - 5 November 2023
    End of Life November 30, 2023

    See also the detailed schedule and the release notes.

    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.

    In practice, you should keep an eye on the tagging of the first release candidate. One way to find out, if RC1 has been tagged is to visit the tag view of the LibreOffice core repository in Gerrit and input into the filter field: libreoffice-X.Y.Z. If the results do not contain any entry for libreoffice-X.Y.Z.1, RC1 has not yet been tagged and string changes can still be committed.

    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.