Application Services Release Process

Nightly builds

Nightly builds are automatically generated using a taskcluster cron task.

  • The results of the latest successful nightly build is listed here: https://firefox-ci-tc.services.mozilla.com/tasks/index/project.application-services.v2.nightly/latest
  • The latest nightly decision task should be listed here: https://firefox-ci-tc.services.mozilla.com/tasks/index/project.application-services.v2.branch.main.latest.taskgraph/decision-nightly
  • If you don't see a decision task from the day before, then contact releng. It's likely that the cron decision task is broken.

Release builds

Release builds are generated from the release-vXXX branches and triggered in Ship-it

  • Whenever a commit is pushed to a release branch, we build candidate artifacts. These artifacts are shippable -- if we decide that the release is ready, they just need to be copied to the correct location.
  • The push phase of release-promotion copies the candidate to a staging location where they can be tested.
  • The ship phase of release-promotion copies the candidate to their final, published, location.

[Release management] Creating a new release

This part is 100% covered by the Release Management team. The dev team should not perform these steps.

On Merge Day we take a snapshot of the current main, and prepare a release. See Firefox Release Calendar.

  1. Create a branch name with the format release-v[release_version] off of the main branch (for example, release-v118) through the GitHub UI. [release_version] should follow the Firefox release number. See Firefox Release Calendar.

  2. Create a PR against the release branch that updates version.txt and updates the CHANGELOG.md as follows:

  • In version.txt, update the version from [release_version].0a1 to [release_version].0.
diff --git a/version.txt b/version.txt
--- a/version.txt
+++ b/version.txt
@@ -1 +1 @@
-118.0a1
+118.0
  • In CHANGELOG.md, change In progress to _YYYY-MM-DD_ to match the Merge Day date and add a URL to the release version change log.
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 7f2c07a1a8..06688fdcab 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,8 +1,7 @@
-# v118.0 (In progress)
-
-[Full Changelog](In progress)
+# v118.0 (_2023-08-28_)
 
 ## General
+
 ### 🦊 What's Changed 🦊
 
 - Backward-incompatible changes to the Suggest database schema to accommodate custom details for providers ([#5745](https://github.com/mozilla/application-services/pull/5745)) and future suggestion types ([#5766](https://github.com/mozilla/application-services/pull/5766)). This only affects prototyping, because we aren't consuming Suggest in any of our products yet.
@@ -16,7 +15,6 @@
 - The Remote Settings client has a new `Client::get_records_with_options()` method ([#5764](https://github.com/mozilla/application-services/pull/5764)). This is for Rust consumers only; it's not exposed to Swift or Kotlin.
 - `RemoteSettingsRecord` objects have a new `deleted` property that indicates if the record is a tombstone ([#5764](https://github.com/mozilla/application-services/pull/5764)).
 
-
 ## Rust log forwarder
 ### 🦊 What's Changed 🦊
 
@@ -34,6 +32,8 @@
 
 - Removed previously deprecated commands `experimenter`, `ios`, `android`, `intermediate-repr` ([#5784](https://github.com/mozilla/application-services/pull/5784)).
 
+[Full Changelog](https://github.com/mozilla/application-services/compare/v117.0...v118.0)
+
 # v117.0 (_2023-07-31_)
  • Create a commit named 'Cut release v[release_version].0` and a PR for this change.
  • See example PR
  1. Create a PR against the main branch that updates version.txt and updates the CHANGELOG.md as follows:
  • In version.txt, update the version from [release_version].0a1 to [next_release_version].0a1.
diff --git a/version.txt b/version.txt
--- a/version.txt
+++ b/version.txt
@@ -1 +1@@
-118.0a1
+119.0a1
  • In CHANGELOG.md, change the in progress version from [release_version].0 to [next_release_version].0, add a header for the previous release version, and add a URL to the previous release version change log.
diff --git a/CHANGELOG.md b/CHANGELOG.md
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,8 +1,7 @@
-# v118.0 (In progress)
+# v119.0 (In progress)

[Full Changelog](In progress)

+# v118.0 (_2023-08-28_)
@@ -34,6 +36,8 @@
+[Full Changelog](https://github.com/mozilla/application-services/compare/v117.0...v118.0)
+
# v117.0 (_2023-07-31_)
  • Create a commit named 'Start release v[next_release_version].0` and a PR for this change.
  • See example PR
  1. Once all of the above PRs have landed, create a new Application Services release in Ship-It.
  • Promote and Ship the release.

  1. Tag the release in the Application Services repo.

  2. Inform the Application Services team to cut a release of rust-components-swift

  • The team will tag the repo and let you know the git hash to use when updating the consumer applications
  1. Update consumer applications

[Release management] Creating a new release via scripts:

  1. Run pip3 install -r automation/requirements.txt to install the required Python packages.
  2. Run the automation/prepare-release.py script. This should:
  • Create a new branch named release-vXXX
  • Create a PR against that branch that updates version.txt like this:
diff --git a/version.txt b/version.txt
index 8cd923873..6482018e0 100644
--- a/version.txt
+++ b/version.txt
@@ -1,4 +1,4 @@
-114.0a1
+114.0
  • Create a PR on main that starts a new CHANGELOG header.
  1. Tag the release with automation/tag-release.py [major-version-number]

Cutting patch releases for uplifted changes (dot-release)

If you want to uplift changes into a previous release:

  • Make sure the changes are present in main and have been thoroughly tested
  • Checkout the release-vXXX branch, where XXX is the major version number
  • Create a PR to bump the version in version.txt from [release_version].0 to [release_version].0.1 on the release branch
  • Cherry-pick any commits that you want to uplift into a PR or ensure all the needed PRs are merged into the release branch
  • Once the PRs are approved, merged, and CI has completed, Create a new Application Services release in Ship-It for the release branch. Promote & ship the release
  • Tag the release in the Application Services repo
  • Inform the Application Services team in case there is a need to cut a new release of rust-components-swift
  • Update consumer applications

What gets built in a release?

We build several artifacts for both nightlies and releases:

  • nightly.json / release.json. This is a JSON file containing metadata from successful builds. The metadata for the latest successful build can be found from a taskcluster index: https://firefox-ci-tc.services.mozilla.com/api/index/v1/task/project.application-services.v2.release.latest/artifacts/public%2Fbuild%2Frelease.json The JSON file contains:
    • The version number for the nightly/release
    • The git commit ID
    • The maven channel for Kotlin packages:
      • maven-production: https://maven.mozilla.org/?prefix=maven2/org/mozilla/appservices/
      • maven-nightly-production: https://maven.mozilla.org/?prefix=maven2/org/mozilla/appservices/nightly/
      • maven-staging: https://maven-default.stage.mozaws.net/?prefix=maven2/org/mozilla/appservices/
      • maven-nightly-staging: https://maven-default.stage.mozaws.net/?prefix=maven2/org/mozilla/appservices/nightly/
    • Links to nimbus-fml.*: used to build Firefox/Focus on Android and iOS
    • Links to *RustComponentsSwift.xcframework.zip: XCFramework archives used to build Firefox/Focus on iOS
    • Link to swift-components.tar.xz: UniFFI-generated swift files which get extracted into the rust-components-swift repository for each release.

Nightly builds

For nightly builds, consumers get the artifacts directly from the taskcluster.

  • For, firefox-android, the nightlies are handled by relbot
  • For, firefox-ios, the nightlies are consumed by rust-components-swift. rust-components-swift makes a github release, which is picked up by a Github action in firefox-ios

Release promotion

For real releases, we use the taskcluster release-promotion action. Release promotion happens in two phases:

  • promote copies the artifacts from taskcluster and moves them to a staging area. This allows for testing the consumer apps with the artifacts.
  • ship copies the artifacts from the staging area to archive.mozilla.org, which serves as their permanent storage area.