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.

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.
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

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

Once all of the above PRs have landed, create a new Application Services release in Ship-It.

Promote and Ship the release.

Tag the release in the Application Services repo.
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

Update consumer applications

firefox-android: Follow the directions in the release checklist
firefox-ios: Follow the directions in the release checklist

[Release management] Creating a new release via scripts:

Run pip3 install -r automation/requirements.txt to install the required Python packages.
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.

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
Find the PR for the changes and add this comment: @mergify backport release-vXXX
Find the Bugzilla bug with the changes and add an uplift request
- Find the attacment corresponding to new PR created from the @mergify comment.
- Click the "details" link
- Set approval-mozilla-beta or approval-mozilla-release to ?
- Save the form
Release management will then:
- Arrange for the backport to be merged
- 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
Notify the Application Services team in case there is a need to cut a new release of rust-components-swift
Notify any affected consumer applications teams.

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.

Cross-platform Rust Components