תוכנית הפצה

From The Document Foundation Wiki
Jump to navigation Jump to search
This page is a translated version of the page ReleasePlan and the translation is 77% complete.
Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎Türkçe • ‎dansk • ‎español • ‎français • ‎italiano • ‎português do Brasil • ‎română • ‎русский • ‎עברית • ‎العربية • ‎فارسی • ‎日本語 • ‎한국어

מבוא

Time-based release trains have been shown to produce the best quality Free software. A time based release is one that does not wait for either features, or bug fixes - but is based (as purely as possible) on time. This enforces discipline in introducing fixes, gives predictability, and allows more regular releasing. It is also the case that we will necessarily release earlier, and then rapidly, incrementally bug fix releases based on the previous stable version. Thus if you have a need for the very highest quality version, it can make sense to defer a move until the first or perhaps second minor point release.

  • LibreOffice does bi-annual, predictable releases that are in sync with other Free Software projects (eg. Gnome) and are at least one month ahead major Linux distribution releases.
  • Synchronizing time-based release schedule with the wider Free Software ecosystem also has huge advantages, by getting our new features, out to users as quickly as possible – with a minimum of distribution cycle lag. In consequence, we aim at six monthly releases, and over time nudge them to align well with the March/September norms.
  • Time-based release trains have been shown to produce the best quality Free software. A time based release is one that does not wait for either features, or bug fixes - but is based (as purely as possible) on time. This enforces discipline in introducing fixes, gives predictability, and allows more regular releasing. It is also the case that we will necessarily release earlier, and then rapidly, incrementally bug fix releases based on the previous stable version. Thus if you have a need for the very highest quality version, it can make sense to defer a move until the first or perhaps second minor point release.
  • There are 2 branches: Fresh (the newest release) and Still (the previous release), which are intended for mainstream feature users and conservative, corporate deployments respectively.
  • As a result, users get new major version every six months with a wide range of features, fixes, and enhancements. In addition, they get many pure bugfix micro releases. The first X.Y.0 release is intended for early adopters. More conservative users are advised to wait for a later X.Y.Z bugfix release.

Note that the dates mentioned in the schedule might get shifted if there are serious technical or other problems with the release. An extra RC might be needed if the final release candidate does not fit the Release Criteria. Such problem would shift the final release by one week or even more.

התרשים המופשט שלהלן מציג את שלוש המהדורות על ציר זמן של 24 חודשים.

עתיד
Fresh
Still

מהדורה 7.4

תאריכים בסיסיים למהדורה הראשונית ולתיקונים
מהדורה הקפאה פרסום
7.4.0 (הקפאה: שבוע 30) שבוע 19 , מאי 9, 2022 - מאי 15, 2022 שבוע 33 , אוג' 15, 2022 - אוג' 21, 2022
7.4.1 שבוע 34 , אוג' 22, 2022 - אוג' 28, 2022 שבוע 37 , ספט' 12, 2022 - ספט' 18, 2022
7.4.2 שבוע 38 , ספט' 19, 2022 - ספט' 25, 2022 שבוע 41 , אוק' 10, 2022 - אוק' 16, 2022
7.4.3 שבוע 44 , אוק' 31, 2022 - נוב' 6, 2022 שבוע 47 , נוב' 21, 2022 - נוב' 27, 2022
7.4.4 שבוע 50 , דצמ' 12, 2022 - דצמ' 18, 2022 שבוע 53 , ינו' 2, 2023 - ינו' 8, 2023
7.4.5 שבוע 07 , פבר' 13, 2023 - פבר' 19, 2023 שבוע 10 , מרץ 6, 2023 - מרץ 12, 2023
7.4.6 שבוע 16 , אפר' 17, 2023 - אפר' 23, 2023 שבוע 19 , מאי 8, 2023 - מאי 14, 2023
סוף החיים 12 ביוני, 2023

ניתן לעיין גם בלו״ז המפורט ובהערות ההפצה.

מהדורה 7.3

תאריכים בסיסיים למהדורה הראשונית ולתיקונים
מהדורה הקפאה פרסום
7.3.0 (הקפאה: שבוע 02) שבוע 43 , אוק' 25, 2021 - אוק' 31, 2021 שבוע 05 , ינו' 31, 2022 - פבר' 6, 2022
7.3.1 שבוע 06 , פבר' 7, 2022 - פבר' 13, 2022 שבוע 09 , פבר' 28, 2022 - מרץ 6, 2022
7.3.2 שבוע 10 , מרץ 7, 2022 - מרץ 13, 2022 שבוע 13 , מרץ 28, 2022 - אפר' 3, 2022
7.3.3 שבוע 15 , אפר' 11, 2022 - אפר' 17, 2022 שבוע 18 , מאי 2, 2022 - מאי 8, 2022
7.3.4 שבוע 20 , מאי 16, 2022 - מאי 22, 2022 שבוע 23 , יוני 6, 2022 - יוני 12, 2022
7.3.5 שבוע 26 , יוני 27, 2022 - יולי 3, 2022 שבוע 29 , יולי 18, 2022 - יולי 24, 2022
7.3.6 שבוע 33 , אוג' 15, 2022 - אוג' 21, 2022 שבוע 36 , ספט' 5, 2022 - ספט' 11, 2022
7.3.7 שבוע 41 , אוק' 10, 2022 - אוק' 16, 2022 שבוע 44 , אוק' 31, 2022 - נוב' 6, 2022
סוף החיים 30 בנובמבר, 2022

ניתן לעיין גם בלו״ז המפורט ובהערות ההפצה.

מהדורה 7.2

תאריכים בסיסיים למהדורה הראשונית ולתיקונים
מהדורה הקפאה פרסום
7.2.0 (הקפאה: שבוע 30) שבוע 19 , מאי 10, 2021 - מאי 16, 2021 שבוע 33 , אוג' 16, 2021 - אוג' 22, 2021
7.2.1 שבוע 34 , אוג' 23, 2021 - אוג' 29, 2021 שבוע 37 , ספט' 13, 2021 - ספט' 19, 2021
7.2.2 שבוע 38 , ספט' 20, 2021 - ספט' 26, 2021 שבוע 41 , אוק' 11, 2021 - אוק' 17, 2021
7.2.3 שבוע 44 , נוב' 1, 2021 - נוב' 7, 2021 שבוע 47 , נוב' 22, 2021 - נוב' 28, 2021
7.2.4 שבוע 48 , נוב' 29, 2021 - דצמ' 5, 2021 שבוע 49 , דצמ' 6, 2021 - דצמ' 12, 2021
7.2.5 שבוע 50 , דצמ' 13, 2021 - דצמ' 19, 2021 שבוע 53 , ינו' 3, 2022 - ינו' 9, 2022
7.2.6 שבוע 07 , פבר' 14, 2022 - פבר' 20, 2022 שבוע 10 , מרץ 7, 2022 - מרץ 13, 2022
7.2.7 שבוע 16 , אפר' 18, 2022 - אפר' 24, 2022 שבוע 19 , מאי 9, 2022 - מאי 15, 2022
סוף החיים 12 ביוני, 2022

ניתן גם לעיין בלו״ז המפורט ובהערות ההפצה.

מהדורה 7.1

תאריכים בסיסיים למהדורה הראשונית ולתיקונים
מהדורה הקפאה פרסום
7.1.0 (הקפאה: שבוע 02) שבוע 43 , אוק' 19, 2020 - אוק' 25, 2020 שבוע 05 , פבר' 1, 2021 - פבר' 7, 2021
7.1.1 שבוע 06 , פבר' 8, 2021 - פבר' 14, 2021 שבוע 09 , מרץ 1, 2021 - מרץ 7, 2021
7.1.2 שבוע 10 , מרץ 8, 2021 - מרץ 14, 2021 שבוע 13 , מרץ 29, 2021 - אפר' 4, 2021
7.1.3 שבוע 15 , אפר' 12, 2021 - אפר' 18, 2021 שבוע 18 , מאי 3, 2021 - מאי 9, 2021
7.1.4 שבוע 20 , מאי 17, 2021 - מאי 23, 2021 שבוע 23 , יוני 7, 2021 - יוני 13, 2021
7.1.5 שבוע 26 , יוני 28, 2021 - יולי 4, 2021 שבוע 29 , יולי 19, 2021 - יולי 25, 2021
7.1.6 שבוע 33 , אוג' 16, 2021 - אוג' 22, 2021 שבוע 36 , ספט' 6, 2021 - ספט' 12, 2021
7.1.7 שבוע 41 , אוק' 11, 2021 - אוק' 17, 2021 שבוע 44 , נוב' 1, 2021 - נוב' 7, 2021
7.1.8 שבוע 48 , נוב' 29, 2021 - דצמ' 5, 2021 שבוע 49 , דצמ' 6, 2021 - דצמ' 12, 2021
סוף החיים 30 בנובמבר, 2021

ניתן לעיין גם בלו״ז המפורט ובהערות ההפצה.

מהדורה 7.0

תאריכים בסיסיים למהדורה הראשונית ולתיקונים
מהדורה הקפאה פרסום
7.0.0 (הקפאה: שבוע 29) שבוע 19 , מאי 4, 2020 - מאי 10, 2020 שבוע 32 , אוג' 3, 2020 - אוג' 9, 2020
7.0.1 שבוע 33 , אוג' 10, 2020 - אוג' 16, 2020 שבוע 36 , אוג' 31, 2020 - ספט' 6, 2020
7.0.2 שבוע 38 , ספט' 14, 2020 - ספט' 20, 2020 שבוע 41 , אוק' 5, 2020 - אוק' 11, 2020
7.0.3 שבוע 43 , אוק' 19, 2020 - אוק' 25, 2020 שבוע 46 , נוב' 9, 2020 - נוב' 15, 2020
7.0.4 שבוע 48 , נוב' 23, 2020 - נוב' 29, 2020 שבוע 51 , דצמ' 14, 2020 - דצמ' 20, 2020
7.0.5 שבוע 07 , פבר' 15, 2021 - פבר' 21, 2021 שבוע 10 , מרץ 8, 2021 - מרץ 14, 2021
7.0.6 שבוע 16 , אפר' 19, 2021 - אפר' 25, 2021 שבוע 19 , מאי 10, 2021 - מאי 16, 2021
סוף החיים 31 במאי, 2021

ניתן לעיין גם בלו״ז המפורט ובהערות ההפצה.

מהדורה 6.4

תאריכים בסיסיים למהדורה הראשונית ולתיקונים
מהדורה הקפאה פרסום
6.4.0 (הקפאה: שבוע 02) שבוע 42 , אוק' 14, 2019 - אוק' 20, 2019 שבוע 05 , ינו' 27, 2020 - פבר' 2, 2020
6.4.1 שבוע 06 , פבר' 3, 2020 - פבר' 9, 2020 שבוע 09 , פבר' 24, 2020 - מרץ 1, 2020
6.4.2 שבוע 09 , פבר' 24, 2020 - מרץ 1, 2020 שבוע 12 , מרץ 16, 2020 - מרץ 22, 2020
6.4.3 שבוע 13 , מרץ 23, 2020 - מרץ 29, 2020 שבוע 16 , אפר' 13, 2020 - אפר' 19, 2020
6.4.4 שבוע 18 , אפר' 27, 2020 - מאי 3, 2020 שבוע 21 , מאי 18, 2020 - מאי 24, 2020
6.4.5 שבוע 24 , יוני 8, 2020 - יוני 14, 2020 שבוע 27 , יוני 29, 2020 - יולי 5, 2020
6.4.6 שבוע 30 , יולי 20, 2020 - יולי 26, 2020 שבוע 33 , אוג' 10, 2020 - אוג' 16, 2020
6.4.7 שבוע 39 , ספט' 21, 2020 - ספט' 27, 2020 שבוע 42 , אוק' 12, 2020 - אוק' 18, 2020
סוף החיים 30 בנובמבר, 2020

ניתן לעיין גם בלו״ז המפורט ובהערות ההפצה.

מהדורה 6.3

תאריכים בסיסיים למהדורה הראשונית ולתיקונים
מהדורה הקפאה פרסום
6.3.0 (הקפאה: שבוע 29) שבוע 19 , מאי 6, 2019 - מאי 12, 2019 שבוע 32 , אוג' 5, 2019 - אוג' 11, 2019
6.3.1 שבוע 32 , אוג' 5, 2019 - אוג' 11, 2019 שבוע 35 , אוג' 26, 2019 - ספט' 1, 2019
6.3.2 שבוע 36 , ספט' 2, 2019 - ספט' 8, 2019 שבוע 39 , ספט' 23, 2019 - ספט' 29, 2019
6.3.3 שבוע 41 , אוק' 7, 2019 - אוק' 13, 2019 שבוע 44 , אוק' 28, 2019 - נוב' 3, 2019
6.3.4 שבוע 47 , נוב' 18, 2019 - נוב' 24, 2019 שבוע 50 , דצמ' 9, 2019 - דצמ' 15, 2019
6.3.5 שבוע 05 , ינו' 27, 2020 - פבר' 2, 2020 שבוע 08 , פבר' 17, 2020 - פבר' 23, 2020
6.3.6 שבוע 15 , אפר' 6, 2020 - אפר' 12, 2020 שבוע 18 , אפר' 27, 2020 - מאי 3, 2020
סוף החיים 29 במאי, 2020

ניתן לעיין גם בלו״ז המפורט ובהערות ההפצה.

תאריכים

המהדורות פרוסות לפי זמנים אך הלו״ז מגדיר שבועות פיסקליים במקום תאריכים מסוימים. זה כדי להעניק גמישות מסוימת. אפשר לעקב את המהדורה בכמה ימים במקרה של תקלות מכריעות, תקלות בבנייה ושלל בעיות טכניות.

The release consists of several beta and release candidate builds. There are needed several actions for each build. The ideal workflow looks like:

  • Monday: commit deadline; reminder is sent to devel, l10n mailing list before it happens
  • Tuesday: the tag is created on a commit that builds and passes unit-, subsequent-, and smoke-tests; tag is announced on the devel and qa mailing lists
  • Wednesday: builds are uploaded on the early pre-release site; they are announced on the devel and qa mailing lists
  • Thursday: builds are uploaded on mirrors. They are announced via many channels, e.g. mailing lists, twitter
  • Friday: builds are available via the official pre-release site

The final release is usually announced on Thursday, few days after the final release candidate is out.

Note that we are very strict about commits to the final release candidate, so full regression test is not needed. It is used as the final build when it passes the needed tests. It is just renamed on mirrors.

לוח זמנים

לוח זמנים זה מבוסס על הכללים הבאים:

  • do the major release every six months and synchronize it (at least one month ahead) with major Linux distributions; it always comes with a wide range of features, fixes, and enhancements
  • do a pure bugfix release every month after the main release until it is good enough even for the most conservative people; do it less frequently afterwards
  • do pure bugfix releases, including security fixes, until the next release is ready for most conservative people
  • do not do two builds the same week.

The result is the following template:

Interlocking releases
אירוע קיץ חורף
x.y הקפאת יכולות יונ(ת) דצמ(ת)
x.y.0 מהדורה ראשונית אוג(ת) פבר(ת)
x.y.1 מהדורת תיקונים ספט(ת) מרץ(ת)
x.y.2 מהדורת תיקונים אוק(ת) אפר(ת)
x.y.3 מהדורת תיקונים נוב(ת) מאי(ת)
x.y.4 מהדורת תיקונים דצמ(ת) יונ(ת)
x.y.5 מהדורת תיקונים פבר(א) אוג(א)
x.y.6 מהדורת תיקונים אפר(א) אוק(א)

כאשר (ת) מציין תחילת חודש, (א) מציין את אמצע החודש ואילו (ס) מציין את סוף החודש.

הקפאת מחרוזות

The release plans for the first version of each major release indicate a "hard English string & UI freeze". The idea is to make the lives of translators easier. The translators should be able to trust that no new translatable strings are added into the UI or Help files between the period of the string freeze and release.

After the first version of a major release is out, correcting mistakes in the UI and Help strings is fine. Any completely new content should target the next major release.

סכמת גרסאות

We do several builds around each release. The following versioning scheme is used:

  • X.Y.0.0.alphaZ - Zth alpha version of the initial release
  • X.Y.0.0.betaZ - Zth beta version of the initial release
  • X.Y.0.Z - Zth release candidate of the initial release, last rc is considered as final and put on the main download page
  • X.Y.1.Z - Zth release candidate of the 1st bugfix release, last rc is considered as final and put on the main download page

It seems to be the best compromise with the following advantages:

  • easy to understand for normal users, alpha, beta flags are known from other projects, so they set reasonable expectations
  • correct alphabetical sorting in RPM, Bugzilla
  • “easy” to parse (alpha/beta strings delimited by dot)

There was a long discussion about this scheme on the mailing list.

Accelerating the release cycle

This acceleration of the release cycle involves some considerable release engineering and QA effort. To reduce the cost of these, we work to provide complete (ie. containing all languages) daily snapshots of the master branch to allow continual testing of code improvements. This works partially already, as can be seen/downloaded from here.

Similarly, we plan to increasingly automate the build process to allow a much lower-touch release flow, and to continue to shrink the footprint of our binaries to allow far more rapid transfer of product-equivalent builds.

End-of-Life Releases

A release normally has a lifetime of around nine months. We consider a release to have reached its End of Life (EOL) one month after the last planned release.

If you want longer term support for a release, you’re encouraged to engage any certified L3 provider who could provide you with the service.

Because of the amount of data, the releases were split out to ReleasePlan/Archive.