ReleasePlan

    From The Document Foundation Wiki

    Introduction

    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 has bi-annual, predictable releases that are synchronized with other Free Software projects (e.g. Gnome) and are at least one month ahead of major Linux distribution releases.
    • Synchronising the time-based release schedule with the wider Free Software ecosystem also has huge benefits in getting our new features out to users as quickly as possible, with a minimum of lag in the distribution cycle. As a result, we are aiming for six monthly releases, in February and August.
    • There are two versions available: the latest release for technology enthusiasts, early adopters and power users, and the previous release - with fewer features but tested for longer - for corporate implementations and more cautious users.
    • As a result, users get a new major release every six months with a wide range of features, fixes and enhancements. They will also receive many bug-fixing 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.3/X.Y.4 bugfix release.

    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.

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

    Future
    Fresh
    Still


    25.2 release

    Basic dates for the initial and bugfix releases
    Release Freeze Publishing
    25.2.0 (freeze: week 02) Week 47 , Nov 18, 2024 - Nov 24, 2024 Announcement: Week 05 , Jan 27, 2025 - Feb 2, 2025
    Mar update: Week 6 , Feb 3, 2025 - Feb 9, 2025
    25.2.1 Week 06 , Feb 3, 2025 - Feb 9, 2025 Announcement: Week 09 , Feb 24, 2025 - Mar 2, 2025
    Mar update: Week 10 , Mar 3, 2025 - Mar 9, 2025
    25.2.2 Week 10 , Mar 3, 2025 - Mar 9, 2025 Announcement: Week 13 , Mar 24, 2025 - Mar 30, 2025
    Mar update: Week 14 , Mar 31, 2025 - Apr 6, 2025
    25.2.3 Week 15 , Apr 7, 2025 - Apr 13, 2025 Announcement: Week 18 , Apr 28, 2025 - May 4, 2025
    Mar update: Week 19 , May 5, 2025 - May 11, 2025
    25.2.4 Week 20 , May 12, 2025 - May 18, 2025 Announcement: Week 23 , Jun 2, 2025 - Jun 8, 2025
    Mar update: Week 24 , Jun 9, 2025 - Jun 15, 2025
    25.2.5 Week 26 , Jun 23, 2025 - Jun 29, 2025 Announcement: Week 29 , Jul 14, 2025 - Jul 20, 2025
    Mar update: Week 30 , Jul 21, 2025 - Jul 27, 2025
    25.2.6 Week 33 , Aug 11, 2025 - Aug 17, 2025 Announcement: Week 36 , Sep 1, 2025 - Sep 7, 2025
    Mar update: Week 37 , Sep 8, 2025 - Sep 14, 2025
    25.2.7 Week 41 , Oct 6, 2025 - Oct 12, 2025 Announcement: Week 44 , Oct 27, 2025 - Nov 2, 2025
    Mar update: Week 45 , Nov 3, 2025 - Nov 9, 2025
    End of Life November 30, 2025

    See also the detailed schedule and the release notes.

    24.8 release

    Basic dates for the initial and bugfix releases
    Release Freeze Publishing
    24.8.0
    feature freeze: week 24
    string & UI freeze: week 27
    Week 30 , Jul 22, 2024 - Jul 28, 2024 Announcement: Week 34 , Aug 19, 2024 - Aug 25, 2024
    Mar update: Week 35 , Aug 26, 2024 - Sep 1, 2024
    24.8.1 Week 34 , Aug 19, 2024 - Aug 25, 2024 Announcement: Week 37 , Sep 9, 2024 - Sep 15, 2024
    Mar update: Week 38 , Sep 16, 2024 - Sep 22, 2024
    24.8.2 Week 38 , Sep 16, 2024 - Sep 22, 2024 Announcement: Week 41 , Oct 7, 2024 - Oct 13, 2024
    Mar update: Week 42 , Oct 14, 2024 - Oct 20, 2024
    24.8.3 Week 43 , Oct 21, 2024 - Oct 27, 2024 Announcement: Week 46 , Nov 11, 2024 - Nov 17, 2024
    Mar update: Week 47 , Nov 18, 2024 - Nov 24, 2024
    24.8.4 Week 48 , Nov 25, 2024 - Dec 1, 2024 Announcement: Week 51 , Dec 16, 2024 - Dec 22, 2024
    Mar update: Week 52 , Dec 23, 2024 - Dec 29, 2024
    24.8.5 Week 5 , Jan 27, 2025 - Feb 2, 2025 Announcement: Week 8 , Feb 17, 2025 - Feb 23, 2025
    Mar update: Week 9 , Feb 24, 2025 - Mar 2, 2025
    24.8.6 Week 10 , Mar 3, 2025 - Mar 9, 2025 Announcement: Week 13 , Mar 24, 2025 - Mar 30, 2025
    Mar update: Week 14 , Mar 31, 2025 - Apr 6, 2025
    24.8.7 Week 16 , Apr 14, 2025 - Apr 20, 2025 Announcement: Week 19 , May 5, 2025 - May 11, 2025
    Mar update: Week 20 , May 12, 2025 - May 18, 2025
    End of Life June 12, 2025

    See also the detailed schedule and the release notes.


    24.2 release

    Basic dates for the initial and bugfix releases
    Release Freeze Publishing
    24.2.0 (freeze: week 02) Week 47 , Nov 20, 2023 - Nov 26, 2023 Announcement: Week 05 , Jan 29, 2024 - Feb 4, 2024
    Mar update: Week 6 , Feb 5, 2024 - Feb 11, 2024
    24.2.1 Week 06 , Feb 5, 2024 - Feb 11, 2024 Announcement: Week 09 , Feb 26, 2024 - Mar 3, 2024
    Mar update: Week 10 , Mar 4, 2024 - Mar 10, 2024
    24.2.2 Week 10 , Mar 4, 2024 - Mar 10, 2024 Announcement: Week 13 , Mar 25, 2024 - Mar 31, 2024
    Mar update: Week 14 , Apr 1, 2024 - Apr 7, 2024
    24.2.3 Week 15 , Apr 8, 2024 - Apr 14, 2024 Announcement: Week 18 , Apr 29, 2024 - May 5, 2024
    Mar update: Week 19 , May 6, 2024 - May 12, 2024
    24.2.4 Week 20 , May 13, 2024 - May 19, 2024 Announcement: Week 23 , Jun 3, 2024 - Jun 9, 2024
    Mar update: Week 24 , Jun 10, 2024 - Jun 16, 2024
    24.2.5 Week 26 , Jun 24, 2024 - Jun 30, 2024 Announcement: Week 29 , Jul 15, 2024 - Jul 21, 2024
    Mar update: Week 30 , Jul 22, 2024 - Jul 28, 2024
    24.2.6 Week 33 , Aug 12, 2024 - Aug 18, 2024 Announcement: Week 36 , Sep 2, 2024 - Sep 8, 2024
    Mar update: Week 37 , Sep 9, 2024 - Sep 15, 2024
    24.2.7 Week 41 , Oct 7, 2024 - Oct 13, 2024 Announcement: Week 44 , Oct 28, 2024 - Nov 3, 2024
    Mar update: Week 45 , Nov 4, 2024 - Nov 10, 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) Week 19 , May 8, 2023 - May 14, 2023 Announcement: Week 34 , Aug 21, 2023 - Aug 27, 2023
    Mar update: Week 35 , Aug 28, 2023 - Sep 3, 2023
    7.6.1 Week 34 , Aug 21, 2023 - Aug 27, 2023 Announcement: Week 37 , Sep 11, 2023 - Sep 17, 2023
    Mar update: Week 38 , Sep 18, 2023 - Sep 24, 2023
    7.6.2 Week 38 , Sep 18, 2023 - Sep 24, 2023 Announcement: Week 39 , Sep 25, 2023 - Oct 1, 2023
    Mar update: Week 40 , Oct 2, 2023 - Oct 8, 2023
    7.6.3 Week 44 , Oct 30, 2023 - Nov 5, 2023 Announcement: Week 47 , Nov 20, 2023 - Nov 26, 2023
    Mar update: Week 48 , Nov 27, 2023 - Dec 3, 2023
    7.6.4 Week 50 , Dec 11, 2023 - Dec 17, 2023 Announcement: Week 53 , Jan 1, 2024 - Jan 7, 2024
    Mar update: Week 54 , Jan 8, 2024 - Jan 14, 2024
    7.6.5 Week 05 , Jan 29, 2024 - Feb 4, 2024 Announcement: Week 08 , Feb 19, 2024 - Feb 25, 2024
    Mar update: Week 9 , Feb 26, 2024 - Mar 3, 2024
    7.6.6 Week 10 , Mar 4, 2024 - Mar 10, 2024 Announcement: Week 13 , Mar 25, 2024 - Mar 31, 2024
    Mar update: Week 14 , Apr 1, 2024 - Apr 7, 2024
    7.6.7 Week 16 , Apr 15, 2024 - Apr 21, 2024 Announcement: Week 19 , May 6, 2024 - May 12, 2024
    Mar update: Week 20 , May 13, 2024 - May 19, 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) Week 47 , Nov 21, 2022 - Nov 27, 2022 Announcement: Week 05 , Jan 30, 2023 - Feb 5, 2023
    Mar update: Week 6 , Feb 6, 2023 - Feb 12, 2023
    7.5.1 Week 06 , Feb 6, 2023 - Feb 12, 2023 Announcement: Week 09 , Feb 27, 2023 - Mar 5, 2023
    Mar update: Week 10 , Mar 6, 2023 - Mar 12, 2023
    7.5.2 Week 10 , Mar 6, 2023 - Mar 12, 2023 Announcement: Week 13 , Mar 27, 2023 - Apr 2, 2023
    Mar update: Week 14 , Apr 3, 2023 - Apr 9, 2023
    7.5.3 Week 15 , Apr 10, 2023 - Apr 16, 2023 Announcement: Week 18 , May 1, 2023 - May 7, 2023
    Mar update: Week 19 , May 8, 2023 - May 14, 2023
    7.5.4 Week 20 , May 15, 2023 - May 21, 2023 Announcement: Week 23 , Jun 5, 2023 - Jun 11, 2023
    Mar update: Week 24 , Jun 12, 2023 - Jun 18, 2023
    7.5.5 Week 26 , Jun 26, 2023 - Jul 2, 2023 Announcement: Week 29 , Jul 17, 2023 - Jul 23, 2023
    Mar update: Week 30 , Jul 24, 2023 - Jul 30, 2023
    7.5.6 Week 33 , Aug 14, 2023 - Aug 20, 2023 Announcement: Week 36 , Sep 4, 2023 - Sep 10, 2023
    Mar update: Week 37 , Sep 11, 2023 - Sep 17, 2023
    7.5.7 Week 38 , Sep 18, 2023 - Sep 24, 2023 Announcement: Week 39 , Sep 25, 2023 - Oct 1, 2023
    Mar update: Week 40 , Oct 2, 2023 - Oct 8, 2023
    7.5.8 Week 41 , Oct 9, 2023 - Oct 15, 2023 Announcement: Week 44 , Oct 30, 2023 - Nov 5, 2023
    Mar update: Week 45 , Nov 6, 2023 - Nov 12, 2023
    End of Life November 30, 2023

    See also the detailed schedule and the release notes.

    Dates

    The release is time-based but the schedule defines calendar weeks instead of exact dates. It is because we are always a bit flexible. The release can be delayed by few days because of blocker bugs, build problems, and other technical issues.

    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.

    Schedule

    The schedule is based on the following rules:

    • 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
    Event Summer Winter
    x.y feature freeze Jun(b) Dec(b)
    x.y.0 first release Aug(b) Feb(b)
    x.y.1 bugfix release Sep(b) Mar(b)
    x.y.2 bugfix release Oct(b) Apr(b)
    x.y.3 bugfix release Nov(b) May(b)
    x.y.4 bugfix release Dec(b) Jun(b)
    x.y.5 bugfix release Feb(m) Aug(m)
    x.y.6 bugfix release Apr(m) Oct(m)

    Where (b) means the beginning of the month, (m) means the middle of the month and (e) means the end of the month.

    String freeze

    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.

    Version scheme

    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.