wiki/src/contribute/release_schedule.mdwn

   1 [[!meta title="Release schedule"]]
   2
   3 [[!toc levels=2]]
   4
   5 Tails has a time-based release schedule, aligned with Firefox ESR
   6 (Extended Support Release) that are put out every 6 weeks:
   7
   8 * <https://wiki.mozilla.org/Releases>
   9 * <https://wiki.mozilla.org/RapidRelease/Calendar>
  10 * <https://mail.mozilla.com/home/akeybl@mozilla.com/Release%20Management.html>
  11 * <https://ftp.mozilla.org/pub/mozilla.org/firefox/releases/>
  12
  13 The rationale was originally [written on
  14 tails-dev](https://mailman.boum.org/pipermail/tails-dev/2012-April/001132.html).
  15
  16 The idea is to put a major Tails release out every 12 weeks, plus
  17 a point release in between. See the [[contribute/calendar]].
  18
  19 Schedule
  20 ========
  21
  22           /          4w         \/   2w    /4d\
  23
  24           previous               RC1    ESR sources
  25           ESR + Tails             |        |
  26           release          freeze |        |  new ESR + Tails
  27           |                     | |        |  release
  28           |                     | |        |  |
  29           ↓                     ↓ ↓        ↓  ↓
  30         ._____._____._____._____._____._____._____.
  31         0     1     2     3     4     5     6
  32
  33 In the above:
  34
  35 * *ESR sources* means the source code for the upcoming Firefox ESR is
  36   available, but the ESR is not officially out yet: it has to go
  37   through Mozilla's QA process first. Sources are generally available
  38   on Friday night (US time).
  39 * *ESR + Tails release* means Mozilla announces the new Firefox ESR,
  40   and we release a new version of Tails (roughly) the same day.
  41   This usually happens on Tuesday night (US time).
  42
  43 What if things go wrong?
  44 ========================
  45
  46 Postponing the final release causes problems for those who have
  47 scheduled time for post-release user support, press work, etc..
  48
  49 Also, changing our mind (i.e. releasing a point-release instead of
  50 a major one) => switching minor/major release schedule for the future
  51 is probably not an option either.
  52
  53 So we need to have a pessimistic enough RC->final schedule to handle
  54 unexpected issues.
  55
  56 Reverting the faulty feature branch is an option too.
  57
  58 Some day, a [[!tails_ticket 5926 desc="freezable APT repository"]]
  59 will remove quite some of the potential for last minute breakage.
  60
  61 Remaining issues
  62 ================
  63
  64 * When to run the test suite: RC1 and/or RC2?