Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Release Plan
Introduction
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.
6.3 release
| Release | Freeze | Publishing |
|---|---|---|
| 6.3.0 (freeze: week 29) | Week 19 , May 6, 2019 - May 12, 2019 | Week 32 , Aug 5, 2019 - Aug 11, 2019 |
| 6.3.1 | Week 32 , Aug 5, 2019 - Aug 11, 2019 | Week 35 , Aug 26, 2019 - Sep 1, 2019 |
| 6.3.2 | Week 36 , Sep 2, 2019 - Sep 8, 2019 | Week 39 , Sep 23, 2019 - Sep 29, 2019 |
| 6.3.3 | Week 41 , Oct 7, 2019 - Oct 13, 2019 | Week 44 , Oct 28, 2019 - Nov 3, 2019 |
| 6.3.4 | Week 47 , Nov 18, 2019 - Nov 24, 2019 | Week 50 , Dec 9, 2019 - Dec 15, 2019 |
| 6.3.5 | Week 04 , Jan 20, 2020 - Jan 26, 2020 | Week 07 , Feb 10, 2020 - Feb 16, 2020 |
| 6.3.6 | Week 15 , Apr 6, 2020 - Apr 12, 2020 | Week 18 , Apr 27, 2020 - May 3, 2020 |
| End of Life | May 29, 2020 | |
6.2 release
| Release | Freeze | Publishing |
|---|---|---|
| 6.2.0 (freeze: week 02) | Week 42 , Oct 15, 2018 - Oct 21, 2018 | Week 06 , Feb 4, 2019 - Feb 10, 2019 |
| 6.2.1 | Week 06 , Feb 4, 2019 - Feb 10, 2019 | Week 09 , Feb 25, 2019 - Mar 3, 2019 |
| 6.2.2 | Week 09 , Feb 25, 2019 - Mar 3, 2019 | Week 12 , Mar 18, 2019 - Mar 24, 2019 |
| 6.2.3 | Week 13 , Mar 25, 2019 - Mar 31, 2019 | Week 16 , Apr 15, 2019 - Apr 21, 2019 |
| 6.2.4 | Week 18 , Apr 29, 2019 - May 5, 2019 | Week 21 , May 20, 2019 - May 26, 2019 |
| 6.2.5 | Week 24 , Jun 10, 2019 - Jun 16, 2019 | Week 27 , Jul 1, 2019 - Jul 7, 2019 |
| 6.2.6 | Week 30 , Jul 22, 2019 - Jul 28, 2019 | Week 33 , Aug 12, 2019 - Aug 18, 2019 |
| 6.2.7 | Week 39 , Sep 23, 2019 - Sep 29, 2019 | Week 42 , Oct 14, 2019 - Oct 20, 2019 |
| End of Life | November 30, 2019 | |
See also the detailed schedule and the release notes.
6.1 release
| Release | Freeze | Publishing |
|---|---|---|
| 6.1.0 (freeze: week 29) | Week 17 , Apr 23, 2018 - Apr 29, 2018 | Week 32 , Aug 6, 2018 - Aug 12, 2018 |
| 6.1.1 (initially week 35) | Week 32 , Aug 6, 2018 - Aug 12, 2018 | Week 37 , Sep 10, 2018 - Sep 16, 2018 |
| 6.1.2 (shortened to one rc) | Week 38 , Sep 17, 2018 - Sep 23, 2018 | Week 39 , Sep 24, 2018 - Sep 30, 2018 |
| 6.1.3 | Week 41 , Oct 8, 2018 - Oct 14, 2018 | Week 44 , Oct 29, 2018 - Nov 4, 2018 |
| 6.1.4 | Week 48 , Nov 26, 2018 - Dec 2, 2018 | Week 51 , Dec 17, 2018 - Dec 23, 2018 |
| 6.1.5 | Week 3 , Jan 14, 2019 - Jan 20, 2019 | Week 6 , Feb 4, 2019 - Feb 10, 2019 |
| 6.1.6 | Week 15 , Apr 8, 2019 - Apr 14, 2019 | Week 18 , Apr 29, 2019 - May 5, 2019 |
| End of Life | May 29, 2019 | |
See also the detailed schedule and the release notes.
6.0 release
| Release | Freeze | Publishing |
|---|---|---|
| 6.0.0 (freeze: week 2) | Week 42 , Oct 16, 2017 - Oct 22, 2017 | Week 5 , Jan 29, 2018 - Feb 4, 2018 |
| 6.0.1 | Week 6 , Feb 5, 2018 - Feb 11, 2018 | Week 6 , Feb 5, 2018 - Feb 11, 2018 |
| 6.0.2 | Week 8 , Feb 19, 2018 - Feb 25, 2018 | Week 9 , Feb 26, 2018 - Mar 4, 2018 |
| 6.0.3 | Week 11 , Mar 12, 2018 - Mar 18, 2018 | Week 14 , Apr 2, 2018 - Apr 8, 2018 |
| 6.0.4 | Week 16 , Apr 16, 2018 - Apr 22, 2018 | Week 19 , May 7, 2018 - May 13, 2018 |
| 6.0.5 | Week 22 , May 28, 2018 - Jun 3, 2018 | Week 25 , Jun 18, 2018 - Jun 24, 2018 |
| 6.0.6 | Week 28 , Jul 9, 2018 - Jul 15, 2018 | Week 31 , Jul 30, 2018 - Aug 5, 2018 |
| 6.0.7 | Week 40 , Oct 1, 2018 - Oct 7, 2018 | Week 43 , Oct 22, 2018 - Oct 28, 2018 |
| End of Life | November 26, 2018 | |
See also the detailed schedule and the release notes.
5.4 release
| Release | Freeze | Publishing |
|---|---|---|
| 5.4.0 (freeze: week 27) | Week 17 , Apr 24, 2017 - Apr 30, 2017 | Week 30 , Jul 24, 2017 - Jul 30, 2017 |
| 5.4.1 | Week 32 , Aug 7, 2017 - Aug 13, 2017 | Week 35 , Aug 28, 2017 - Sep 3, 2017 |
| 5.4.2 | Week 37 , Sep 11, 2017 - Sep 17, 2017 | Week 40 , Oct 2, 2017 - Oct 8, 2017 |
| 5.4.3 | Week 42 , Oct 16, 2017 - Oct 22, 2017 | Week 45 , Nov 6, 2017 - Nov 12, 2017 |
| 5.4.4 | Week 48 , Nov 27, 2017 - Dec 3, 2017 | Week 51 , Dec 18, 2017 - Dec 24, 2017 |
| 5.4.5 | Week 4 , Jan 22, 2018 - Jan 28, 2018 | Week 6 , Feb 5, 2018 - Feb 11, 2018 |
| 5.4.6 | Week 9 , Feb 26, 2018 - Mar 4, 2018 | Week 12 , Mar 19, 2018 - Mar 25, 2018 |
| 5.4.7 | Week 15 , Apr 9, 2018 - Apr 15, 2018 | Week 18 , Apr 30, 2018 - May 6, 2018 |
| End of Life | June 11, 2018 | |
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; and
- 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; and
- do not do two builds the same week.
The result is the following template:
| 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.
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; and
- 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; and
- “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.
