Release Schedule for Ubuntu Touch

The LandingTeam is responsible for managing and coordinating Releases of the Ubuntu Phone image on request of the Canonical Product team.

Requirements

• The Product Team requests an OTA update release every ~6 weeks for all officially supported products
• In case another release is required out of the standard timeframe, the Product Team needs to inform the Landing Team at least two weeks before the planned release, also officially announcing it on the mailing list (OTA point releases)
• The Product Team hands the Landing Team a list of blocking Bugs together with the request for the milestone, this list gets published along with the above email so developers are aware of the urgency of the open issues. This bug list can be modified during the following weeks towards the milestone, the Product team is the gatekeeper for adding/removing bugs.
• One week before the Release preparation period a translation freeze is introduced. After the freeze no landings containing changes or additions to user-visible strings will be allowed until after release.
• During the Release preparation period (see timeline below) a snapshot of the release candidate is made to the snapshot PPA and all re-spins are prepared in the rc channel. The snapshot is updated with cherry-picks from the overlay whenever a regression needs to be fixed.
• During the Release preparation period normal landings are enabled normally, with rc-proposed images containing the daily changes. This means that there is always an overlap between the end of the current OTA preparation and the start of the next one.

Timeline

Friday (US TZ) EOD (3rd week)

• All user visible strings are now landed in the image, no silos with additional string changes are allowed to be released to the archive.

Friday (US TZ) EOD (4th week)

• The Final Freeze gets called out by the LandingTeam. No landings are accepted by the LandingTeam or the QA Team for the selected milestone besides ship blockers and rare ProductTeam approved exceptions.

Saturday (EU TZ) (4th week)

• The first automated candidate image is built to the rc-proposed channel.

Monday morning (EU TZ) (5th week)

• The overlay PPA state for the candidate image is copied to the snapshot PPA.
• The first candidate image is copied from rc-proposed to the rc channel.

• The QA team starts the regression tests of the candidate image, in case severe regressions are found, the developer of the component gets contacted and a silo with a fix gets prepared.

• Landings to the overlay PPA are allowed but limited by QA resources, as QA engineers prioritize release candidate testing over silos.
• Whenever QA finds a blocking regression and a fix is prepared, the fix is cherry-picked to the snapshot PPA and a new rc image is rebuilt.
• This means that the development work on the next OTA starts on this day.

Friday EOD (US TZ) (6th week)

• Testing of the candidate image on the desired target architectures is finished, the LandingTeam is notified about the status.

• Information about a valid image candidate is sent to the manufacturers for testing.
• Some manufacturers can receive image candidates earlier as to not waste time.

Monday morning (EU TZ) (7th week)

• The QA team runs a quick test on the community architectures that will have to be promoted alongside the product image (mako, emulator, etc) and gives a recommendation about realisability of these images to the LandingTeam.

Tuesday evening (EU TZ) (7th week)

• The final manufacturers return feedback regarding the realisability of the OTA.
• A final decision is made based off the decisions of QA, Product management, manufacturers feedback and the Landing Team. The Product Team always have the possibility to veto any of the decisions.

Wednesday noon (EU TZ) (7th week)

• The LandingTeam releases the Milestone. The candidate image is copied from RC to stable for all approved channels and devices (ubuntu-touch/stable/*).

• Phased updates are started for the new stable image.

Thursday morning (EU TZ) (7th week)

• Phased updates are over, all users should see update notifications.

Schedule Overview

Hotfix Releases

The Product Team can request a hotfix point-release at least two weeks prior to the planned release at any time between main milestones. A hotfix release is tagged with OTA-<X>.<R>, where <X> is the update that's used as base (always the latest stable OTA is used) and <R> is the release revision. The Product Team needs to provide a list of critical fixes/changes that are to be used in the hotfix release (usually as a separate LP milestone).

Hotfix releases are usually composed of critical bug and security fixes that cannot wait with their release until the next milestone. The Landing Team then prepares the snapshot PPA with the state of the latest stable release and cherry-picks packages from the stable-phone-overlay that carry the required fixes. Sometimes, if a package containing a critical fix carries too many other unrelated changes that could potentially cause regressions or significantly increase testing time, a code cherry-pick for the project can be requested. A CI Train silo is then allocated with a temporary dependency-switch to the snapshot PPA and the required package is rebuilt there with only the wanted changes. The ubuntu-touch/rc/* channels are used for building and testing the hotfix images.

Hotfix release dates are generally very flexible but due to the nature of our QA processes usually the official start of phased upgrades is on Wednesdays.