תוכנית הפצה
TDF LibreOffice Document Liberation Project בלוגים קהילתיים Weblate Nextcloud Redmine Ask LibreOffice תרומה
מבוא
Time-based releases have been shown to produce the best quality free software. A time-based release is one that does not wait for features or bug fixes, but is based (as purely as possible) on time. This enforces discipline in introducing fixes, provides predictability, and allows for more regular releases. It is also the case that we will necessarily release earlier, and then rapidly, incrementally, bug fix releases based on the previous stable release. So, if you have a need for the very highest quality release, it may make sense to delay a move until the first or perhaps second minor point release.
- מיזם LibreOffice משחרר מהדורות במועדים שנקבעו מראש ומסונכרנים עם מיזמי תוכנה חופשית נוספים (למשל: Gnome) והם לפחות חודש לפני מועדי שחרור של מהדורות הפצות לינוקס עיקריות.
- לסנכרון לוח זמנים של מהדורות קצובות בזמן מול סביבת התוכנה החופשית יש גם המון יתרונות, למשל הפצת יכולות חדשות ישירות למשתמשים במהירות האפשרית - תוך כמה שפחות הפרעות בפערי המחזור. כתוצאה מכך, אנו מכוונים למהדורות בטווחים של שישה חודשים ועם הזמן מנדנדים להם להתיישר כמו שצריך עם התרגולות הקבועות של מרץ/ספטמבר.
- קיימים שני ענפים: Fresh (רעננה - הגרסה העדכנית ביותר) ו־Still (דוממת - הגרסה הקודמת), שמיועדים למשתמשים ביכולות הרגילות ולהטמעות מסורתיות ארגוניות בהתאמה.
- כתוצאה מכך, משתמשים מקבלים גרסאות עיקריות חדשות כל חצי שנה עם מגוון רחב של יכולות, תיקונים והרחבות. בנוסף, הם זוכים לגרסאות מזעריות עם תיקוני תקלות. מהדורת X.Y.0 הראשונה מיועדת למשתמשים מוקדמים. למשתמשים מסורתיים יותר מומלץ להמתין למהדורות X.Y.Z המאוחרות יותר עם תיקוני תקלות.
Note that the dates in this schedule may change if there are serious technical or other problems with the release. An extra RC might be needed if the final release candidate has a catastrophic problem. Such a problem could delay the final release by a week or more. The decision should be made at a meeting of the Engineering Steering Committee.
התרשים המופשט שלהלן מציג את שלוש המהדורות על ציר זמן של 24 חודשים.
25.2 release
| Release | Freeze | Publishing |
|---|---|---|
| 25.2.0 (freeze: week 02) | שבוע 47 , נוב' 18, 2024 - נוב' 24, 2024 | שבוע 05 , ינו' 27, 2025 - פבר' 2, 2025 |
| 25.2.1 | שבוע 06 , פבר' 3, 2025 - פבר' 9, 2025 | שבוע 09 , פבר' 24, 2025 - מרץ 2, 2025 |
| 25.2.2 | שבוע 10 , מרץ 3, 2025 - מרץ 9, 2025 | שבוע 13 , מרץ 24, 2025 - מרץ 30, 2025 |
| 25.2.3 | שבוע 15 , אפר' 7, 2025 - אפר' 13, 2025 | שבוע 18 , אפר' 28, 2025 - מאי 4, 2025 |
| 25.2.4 | שבוע 20 , מאי 12, 2025 - מאי 18, 2025 | שבוע 23 , יוני 2, 2025 - יוני 8, 2025 |
| 25.2.5 | שבוע 26 , יוני 23, 2025 - יוני 29, 2025 | שבוע 29 , יולי 14, 2025 - יולי 20, 2025 |
| 25.2.6 | שבוע 33 , אוג' 11, 2025 - אוג' 17, 2025 | שבוע 36 , ספט' 1, 2025 - ספט' 7, 2025 |
| 25.2.7 | שבוע 41 , אוק' 6, 2025 - אוק' 12, 2025 | שבוע 44 , אוק' 27, 2025 - נוב' 2, 2025 |
| End of Life | November 30, 2025 | |
See also the detailed schedule and the release notes.
24.8 release
| Release | Freeze | Publishing |
|---|---|---|
| {{{5}}} | שבוע 30 , יולי 22, 2024 - יולי 28, 2024 | שבוע 34 , אוג' 19, 2024 - אוג' 25, 2024 |
| 24.8.1 | שבוע 34 , אוג' 19, 2024 - אוג' 25, 2024 | שבוע 37 , ספט' 9, 2024 - ספט' 15, 2024 |
| 24.8.2 | שבוע 38 , ספט' 16, 2024 - ספט' 22, 2024 | שבוע 41 , אוק' 7, 2024 - אוק' 13, 2024 |
| 24.8.3 | שבוע 43 , אוק' 21, 2024 - אוק' 27, 2024 | שבוע 46 , נוב' 11, 2024 - נוב' 17, 2024 |
| 24.8.4 | שבוע 48 , נוב' 25, 2024 - דצמ' 1, 2024 | שבוע 51 , דצמ' 16, 2024 - דצמ' 22, 2024 |
| 24.8.5 | שבוע 5 , ינו' 27, 2025 - פבר' 2, 2025 | שבוע 8 , פבר' 17, 2025 - פבר' 23, 2025 |
| 24.8.6 | שבוע 10 , מרץ 3, 2025 - מרץ 9, 2025 | שבוע 13 , מרץ 24, 2025 - מרץ 30, 2025 |
| 24.8.7 | שבוע 16 , אפר' 14, 2025 - אפר' 20, 2025 | שבוע 19 , מאי 5, 2025 - מאי 11, 2025 |
| End of Life | June 12, 2025 | |
See also the detailed schedule and the release notes.
מהדורה 24.2
| מהדורה | הקפאה | פרסום |
|---|---|---|
| 24.2.0 (הקפאה: שבוע 02) | שבוע 47 , נוב' 20, 2023 - נוב' 26, 2023 | שבוע 05 , ינו' 29, 2024 - פבר' 4, 2024 |
| 24.2.1 | שבוע 06 , פבר' 5, 2024 - פבר' 11, 2024 | שבוע 09 , פבר' 26, 2024 - מרץ 3, 2024 |
| 24.2.2 | שבוע 10 , מרץ 4, 2024 - מרץ 10, 2024 | שבוע 13 , מרץ 25, 2024 - מרץ 31, 2024 |
| 24.2.3 | שבוע 15 , אפר' 8, 2024 - אפר' 14, 2024 | שבוע 18 , אפר' 29, 2024 - מאי 5, 2024 |
| 24.2.4 | שבוע 20 , מאי 13, 2024 - מאי 19, 2024 | שבוע 23 , יוני 3, 2024 - יוני 9, 2024 |
| 24.2.5 | שבוע 26 , יוני 24, 2024 - יוני 30, 2024 | שבוע 29 , יולי 15, 2024 - יולי 21, 2024 |
| 24.2.6 | שבוע 33 , אוג' 12, 2024 - אוג' 18, 2024 | שבוע 36 , ספט' 2, 2024 - ספט' 8, 2024 |
| 24.2.7 | שבוע 41 , אוק' 7, 2024 - אוק' 13, 2024 | שבוע 44 , אוק' 28, 2024 - נוב' 3, 2024 |
| סוף החיים | 30 בנובמבר, 2024 | |
See also the detailed schedule and the release notes.
מהדורה 7.6
| מהדורה | הקפאה | פרסום |
|---|---|---|
| 7.6.0 (הקפאה: שבוע 30) | שבוע 19 , מאי 8, 2023 - מאי 14, 2023 | שבוע 34 , אוג' 21, 2023 - אוג' 27, 2023 |
| 7.6.1 | שבוע 34 , אוג' 21, 2023 - אוג' 27, 2023 | שבוע 37 , ספט' 11, 2023 - ספט' 17, 2023 |
| 7.6.2 | שבוע 38 , ספט' 18, 2023 - ספט' 24, 2023 | שבוע 39 , ספט' 25, 2023 - אוק' 1, 2023 |
| 7.6.3 | שבוע 44 , אוק' 30, 2023 - נוב' 5, 2023 | שבוע 47 , נוב' 20, 2023 - נוב' 26, 2023 |
| 7.6.4 | שבוע 50 , דצמ' 11, 2023 - דצמ' 17, 2023 | שבוע 53 , ינו' 1, 2024 - ינו' 7, 2024 |
| 7.6.5 | שבוע 05 , ינו' 29, 2024 - פבר' 4, 2024 | שבוע 08 , פבר' 19, 2024 - פבר' 25, 2024 |
| 7.6.6 | שבוע 10 , מרץ 4, 2024 - מרץ 10, 2024 | שבוע 13 , מרץ 25, 2024 - מרץ 31, 2024 |
| 7.6.7 | שבוע 16 , אפר' 15, 2024 - אפר' 21, 2024 | שבוע 19 , מאי 6, 2024 - מאי 12, 2024 |
| סוף החיים | 12 ביוני, 2024 | |
ניתן לעיין גם בלו״ז המפורט ובהערות ההפצה.
מהדורה 7.5
| מהדורה | הקפאה | פרסום |
|---|---|---|
| 7.5.0 (הקפאה: שבוע 02) | שבוע 47 , נוב' 21, 2022 - נוב' 27, 2022 | שבוע 05 , ינו' 30, 2023 - פבר' 5, 2023 |
| 7.5.1 | שבוע 06 , פבר' 6, 2023 - פבר' 12, 2023 | שבוע 09 , פבר' 27, 2023 - מרץ 5, 2023 |
| 7.5.2 | שבוע 10 , מרץ 6, 2023 - מרץ 12, 2023 | שבוע 13 , מרץ 27, 2023 - אפר' 2, 2023 |
| 7.5.3 | שבוע 15 , אפר' 10, 2023 - אפר' 16, 2023 | שבוע 18 , מאי 1, 2023 - מאי 7, 2023 |
| 7.5.4 | שבוע 20 , מאי 15, 2023 - מאי 21, 2023 | שבוע 23 , יוני 5, 2023 - יוני 11, 2023 |
| 7.5.5 | שבוע 26 , יוני 26, 2023 - יולי 2, 2023 | שבוע 29 , יולי 17, 2023 - יולי 23, 2023 |
| 7.5.6 | שבוע 33 , אוג' 14, 2023 - אוג' 20, 2023 | שבוע 36 , ספט' 4, 2023 - ספט' 10, 2023 |
| 7.5.7 | שבוע 38 , ספט' 18, 2023 - ספט' 24, 2023 | שבוע 39 , ספט' 25, 2023 - אוק' 1, 2023 |
| 7.5.8 | שבוע 41 , אוק' 9, 2023 - אוק' 15, 2023 | שבוע 44 , אוק' 30, 2023 - נוב' 5, 2023 |
| סוף החיים | 30 בנובמבר, 2023 | |
ניתן לעיין גם בלו״ז המפורט ובהערות ההפצה.
תאריכים
המהדורות פרוסות לפי זמנים אך הלו״ז מגדיר שבועות פיסקליים במקום תאריכים מסוימים. זה כדי להעניק גמישות מסוימת. אפשר לעקב את המהדורה בכמה ימים במקרה של תקלות מכריעות, תקלות בבנייה ושלל בעיות טכניות.
השחרור מורכב ממספר בניות בטא ומיועדות להפצה. יש מספר פעולות נחוצות לכל בנייה. התהליך המיטבי נראה כך:
- 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.
התוצאה היא התבנית הבאה:
| אירוע | קיץ | חורף |
|---|---|---|
| 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.
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.
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.