Updating the release process and scripts
Updated/added scripts to handle releases. Renamed `cut-an-new-release.md` to `releases.md` and updated the contents. Removed CHANGES_UNRELEASED. The new release system is simple enough that we can just write entries directly to the changelog.
This commit is contained in:
Ben Dean-Kawamura
bendk
Родитель
7ab0b4a631
Коммит
d853bd4847
|
|
@ -5,7 +5,7 @@
|
|||
- For changes that need extra cross-platform testing, consider adding `[ci full]` to the PR title.
|
||||
- If this pull request includes a breaking change, consider [cutting a new release](https://github.com/mozilla/application-services/blob/main/docs/howtos/cut-a-new-release.md) after merging.
|
||||
- [ ] **Tests**: This PR includes thorough tests or an explanation of why it does not
|
||||
- [ ] **Changelog**: This PR includes a changelog entry in [CHANGES_UNRELEASED.md](../CHANGES_UNRELEASED.md) or an explanation of why it does not need one
|
||||
- [ ] **Changelog**: This PR includes a changelog entry in [CHANGELOG.md](../CHANGELOG.md) or an explanation of why it does not need one
|
||||
- Any breaking changes to Swift or Kotlin binding APIs are noted explicitly
|
||||
- [ ] **Dependencies**: This PR follows our [dependency management guidelines](https://github.com/mozilla/application-services/blob/main/docs/dependency-management.md)
|
||||
- Any new dependencies are accompanied by a summary of the due dilligence applied in selecting them.
|
||||
|
|
|
|||
26
CHANGELOG.md
26
CHANGELOG.md
|
|
@ -1,3 +1,29 @@
|
|||
# v114.0 (In progress)
|
||||
|
||||
[Full Changelog](In progress)
|
||||
|
||||
## General
|
||||
|
||||
### ✨ What's New ✨
|
||||
- Updated the version system to follow the Firefox major version
|
||||
- Implemented nightly builds
|
||||
|
||||
## Nimbus ⛅️🔬🔭
|
||||
|
||||
### ✨ What's New ✨
|
||||
|
||||
- Added processing of command line arguments (or intent extras) to be driven by a command line tool. ([#5482](https://github.com/mozilla/application-services/pull/5482))
|
||||
- Requires passing `CommandLine.arguments` to `NimbusBuilder` in iOS.
|
||||
- Requires passing `intent` to `NimbusInterface` in Android.
|
||||
- Added Cirrus client object for working with Nimbus in a static, stateless manner ([#5471](https://github.com/mozilla/application-services/pull/5471)).
|
||||
- Added [`nimbus-cli`](./components/support/nimbus-cli). ([#5494](https://github.com/mozilla/application-services/pull/5494))
|
||||
|
||||
## Places ⛅️🔬🔭
|
||||
|
||||
### 🦊 What's Changed 🦊
|
||||
|
||||
- Added support for sync payload evolution in history. If other clients sync history records / visits with fields that we don't know about, we store that data as JSON and send it back when it's synced next.
|
||||
|
||||
# v97.5.1 (_2023-04-17_)
|
||||
|
||||
[Full Changelog](https://github.com/mozilla/application-services/compare/v97.5.0...v97.5.1)
|
||||
|
|
|
|||
|
|
@ -1,37 +0,0 @@
|
|||
**See [the release process docs](docs/howtos/cut-a-new-release.md) for the steps to take when cutting a new release.**
|
||||
|
||||
# Unreleased Changes
|
||||
|
||||
[Full Changelog](https://github.com/mozilla/application-services/compare/v97.5.1...main)
|
||||
|
||||
<!-- WARNING: New entries should be added below this comment to ensure the `./automation/prepare-release.py` script works as expected.
|
||||
|
||||
Use the template below to make assigning a version number during the release cutting process easier.
|
||||
|
||||
## [Component Name]
|
||||
|
||||
### ⚠️ Breaking Changes ⚠️
|
||||
- Description of the change with a link to the pull request ([#0000](https://github.com/mozilla/application-services/pull/0000))
|
||||
### 🦊 What's Changed 🦊
|
||||
- Description of the change with a link to the pull request ([#0000](https://github.com/mozilla/application-services/pull/0000))
|
||||
### ✨ What's New ✨
|
||||
- Description of the change with a link to the pull request ([#0000](https://github.com/mozilla/application-services/pull/0000))
|
||||
|
||||
-->
|
||||
## Nimbus ⛅️🔬🔭
|
||||
|
||||
### ✨ What's New ✨
|
||||
|
||||
- Added processing of command line arguments (or intent extras) to be driven by a command line tool. ([#5482](https://github.com/mozilla/application-services/pull/5482), [#5497](https://github.com/mozilla/application-services/pull/5497))
|
||||
- Requires passing `CommandLine.arguments` to `NimbusBuilder` in iOS.
|
||||
- Requires passing `intent` to `NimbusInterface` in Android.
|
||||
- Added Cirrus client object for working with Nimbus in a static, stateless manner ([#5471](https://github.com/mozilla/application-services/pull/5471)).
|
||||
- Added Cirrus client UDL bindings ([#5475](https://github.com/mozilla/application-services/pull/5475)).
|
||||
- *NOTE:* The Cirrus UDL bindings are only intended to function with Python, additional types should be set in the `uniffi.toml` if another language is needed.
|
||||
- Added [`nimbus-cli`](./components/support/nimbus-cli). ([#5494](https://github.com/mozilla/application-services/pull/5494))
|
||||
|
||||
## Places ⛅️🔬🔭
|
||||
|
||||
### 🦊 What's Changed 🦊
|
||||
|
||||
- Added support for sync payload evolution in history. If other clients sync history records / visits with fields that we don't know about, we store that data as JSON and send it back when it's synced next.
|
||||
|
|
@ -2,163 +2,110 @@
|
|||
|
||||
# Purpose: Prepare an Application-Services release
|
||||
# Dependencies: yaml
|
||||
# Usage: ./automation/prepare-release.py minor
|
||||
# Usage: ./automation/prepare-release.py
|
||||
|
||||
import argparse
|
||||
from datetime import datetime
|
||||
import subprocess
|
||||
import re
|
||||
import webbrowser
|
||||
import yaml
|
||||
|
||||
from shared import step_msg, fatal_err, run_cmd_checked, ensure_working_tree_clean
|
||||
|
||||
parser = argparse.ArgumentParser(description="Prepares an application-services release "
|
||||
"(increment versions, write changelog, send PR to GitHub).")
|
||||
parser.add_argument("release_type",
|
||||
choices=["major", "minor", "patch"],
|
||||
help="The release type to be done. See https://semver.org/ for guidance.")
|
||||
parser.add_argument("--base-branch",
|
||||
default="main",
|
||||
help="The branch to make a release from. Default is main.")
|
||||
parser.add_argument("--remote",
|
||||
default="origin",
|
||||
help="The remote name that corresponds to the Application Services main repository.")
|
||||
|
||||
args = parser.parse_args()
|
||||
base_branch = args.base_branch
|
||||
remote = args.remote
|
||||
release_type = args.release_type
|
||||
from shared import (RefNames, get_moz_remote, step_msg, fatal_err, run_cmd_checked,
|
||||
ensure_working_tree_clean, check_output)
|
||||
|
||||
# Constants
|
||||
BUILDCONFIG_FILE = ".buildconfig-android.yml"
|
||||
BUILDCONFIG_VERSION_FIELD = "libraryVersion"
|
||||
UNRELEASED_CHANGES_FILE = "CHANGES_UNRELEASED.md"
|
||||
CHANGELOG_FILE = "CHANGELOG.md"
|
||||
|
||||
# 1. Create a new branch based on the branch we want to release from.
|
||||
# 1. Figure out which remote to push to
|
||||
moz_remote = get_moz_remote()
|
||||
|
||||
# 2. Figure out the current version
|
||||
with open(BUILDCONFIG_FILE, "r") as stream:
|
||||
build_config = yaml.safe_load(stream)
|
||||
|
||||
cur_version = build_config[BUILDCONFIG_VERSION_FIELD]
|
||||
major_version_number = int(cur_version.split('.')[0])
|
||||
release_version = f"{major_version_number}.0"
|
||||
refs = RefNames(major_version_number, 0)
|
||||
|
||||
# 3. Create a new branch based on the branch we want to release from.
|
||||
|
||||
if check_output(["git", "rev-parse", "--abbrev-ref", "HEAD"]).strip() != refs.main:
|
||||
fatal_err(f"automation/prepare-release.py must be run from the {refs.main} branch")
|
||||
ensure_working_tree_clean()
|
||||
|
||||
step_msg(f"Calculating remote owner {remote}")
|
||||
result = run_cmd_checked(["git", "remote", "get-url", remote], stdout=subprocess.PIPE)
|
||||
repo_url = result.stdout.decode('utf8').strip()
|
||||
repo_owner_patterns = [
|
||||
r"git@github.com:(.*?)/application-services.git",
|
||||
r'https://github.com/(.*?)/application-services.git',
|
||||
]
|
||||
for pattern in repo_owner_patterns:
|
||||
match = re.match(pattern, repo_url)
|
||||
if match:
|
||||
repo_owner = match.group(1)
|
||||
break
|
||||
else:
|
||||
fatal_err(f"Error parsing remote URL: {repo_url}")
|
||||
print(f"Parsed github owner {repo_owner} for {repo_url}")
|
||||
step_msg(f"Creating {refs.release}")
|
||||
run_cmd_checked(["git", "checkout", "-b", refs.release])
|
||||
run_cmd_checked(["git", "push", moz_remote, refs.release])
|
||||
|
||||
step_msg(f"Updating remote {remote}")
|
||||
run_cmd_checked(["git", "remote", "update", remote])
|
||||
# 4. Create a PR to update the release branch
|
||||
|
||||
temp_branch = f"prepare-release-from-{base_branch}"
|
||||
step_msg(f"Checking out candidate release branch from {base_branch}")
|
||||
run_cmd_checked(["git", "checkout", "-b", temp_branch, "--no-track", f"{remote}/{base_branch}"])
|
||||
|
||||
# 2. Calculate new version number based on what's in the base branch.
|
||||
|
||||
with open(BUILDCONFIG_FILE, "r") as stream:
|
||||
buildConfig = yaml.safe_load(stream)
|
||||
|
||||
cur_version = buildConfig[BUILDCONFIG_VERSION_FIELD]
|
||||
cur_version_full = f"v{cur_version}"
|
||||
[major, minor, patch] = map(lambda n: int(n), cur_version.split(".", 3))
|
||||
|
||||
if release_type == "major":
|
||||
major += 1
|
||||
minor = 0
|
||||
patch = 0
|
||||
elif release_type == "minor":
|
||||
minor += 1
|
||||
patch = 0
|
||||
elif release_type == "patch":
|
||||
patch += 1
|
||||
|
||||
next_version = f"{major}.{minor}.{patch}"
|
||||
next_version_full = f"v{next_version}"
|
||||
|
||||
release_branch = f"cut-{next_version_full}"
|
||||
step_msg(f"Preparing release branch {release_branch} for {next_version_full}")
|
||||
run_cmd_checked(["git", "branch", "-M", temp_branch, release_branch])
|
||||
|
||||
# 3. Bump YML version
|
||||
step_msg(f"checkout {refs.release_pr}")
|
||||
run_cmd_checked(["git", "checkout", "-b", refs.release_pr])
|
||||
|
||||
step_msg(f"Bumping version in {BUILDCONFIG_FILE}")
|
||||
buildConfig[BUILDCONFIG_VERSION_FIELD] = next_version
|
||||
build_config[BUILDCONFIG_VERSION_FIELD] = f"{major_version_number}.0"
|
||||
|
||||
with open(BUILDCONFIG_FILE, "w") as stream:
|
||||
yaml.dump(buildConfig, stream, sort_keys=False)
|
||||
|
||||
# 4. Process changelog files
|
||||
|
||||
with open(UNRELEASED_CHANGES_FILE, "r") as stream:
|
||||
unreleased_changes = stream.read()
|
||||
|
||||
# Copy the text after the end of the header comment section in the unreleased changes file.
|
||||
to_find = re.escape("-->")
|
||||
|
||||
changes = re.split(f"^{to_find}$", unreleased_changes, flags=re.MULTILINE)[1].strip()
|
||||
yaml.dump(build_config, stream, sort_keys=False)
|
||||
|
||||
step_msg(f"updating {CHANGELOG_FILE}")
|
||||
with open(CHANGELOG_FILE, "r") as stream:
|
||||
changelog = stream.read()
|
||||
changelog = stream.read().splitlines()
|
||||
|
||||
if changelog[0] != f"# v{major_version_number}.0 (In progress)":
|
||||
fatal_err(f"Unexpected first changelog line: {changelog[0]}")
|
||||
today_date = datetime.today().strftime("%Y-%m-%d")
|
||||
|
||||
new_changelog = f"""# {next_version_full} (_{today_date}_)
|
||||
|
||||
[Full Changelog](https://github.com/mozilla/application-services/compare/{cur_version_full}...{next_version_full})
|
||||
|
||||
{changes}
|
||||
|
||||
{changelog}"""
|
||||
|
||||
new_changes_unreleased = f"""**See [the release process docs](docs/howtos/cut-a-new-release.md) for the steps to take when cutting a new release.**
|
||||
|
||||
# Unreleased Changes
|
||||
|
||||
[Full Changelog](https://github.com/mozilla/application-services/compare/{next_version_full}...main)
|
||||
|
||||
<!-- WARNING: New entries should be added below this comment to ensure the `./automation/prepare-release.py` script works as expected.
|
||||
|
||||
Use the template below to make assigning a version number during the release cutting process easier.
|
||||
|
||||
## [Component Name]
|
||||
|
||||
### ⚠️ Breaking Changes ⚠️
|
||||
- Description of the change with a link to the pull request ([#0000](https://github.com/mozilla/application-services/pull/0000))
|
||||
### 🦊 What's Changed 🦊
|
||||
- Description of the change with a link to the pull request ([#0000](https://github.com/mozilla/application-services/pull/0000))
|
||||
### ✨ What's New ✨
|
||||
- Description of the change with a link to the pull request ([#0000](https://github.com/mozilla/application-services/pull/0000))
|
||||
|
||||
-->
|
||||
"""
|
||||
for i in range(10):
|
||||
if changelog[i] == "[Full Changelog](In progress)":
|
||||
changelog[i] = (
|
||||
f"[Full Changelog](https://github.com/mozilla/application-services/compare/"
|
||||
f"{refs.previous_version_tag}...{refs.version_tag})"
|
||||
)
|
||||
break
|
||||
else:
|
||||
fatal_err(f"Can't find `[Full Changelog](In progress)` line in CHANGELOG.md")
|
||||
|
||||
changelog[0] = f"# v{major_version_number}.0 (_{today_date}_)"
|
||||
with open(CHANGELOG_FILE, "w") as stream:
|
||||
stream.write(new_changelog)
|
||||
|
||||
with open(UNRELEASED_CHANGES_FILE, "w") as stream:
|
||||
stream.write(new_changes_unreleased)
|
||||
|
||||
# 5. Create a commit and send a PR
|
||||
stream.write("\n".join(changelog))
|
||||
|
||||
step_msg(f"Creating a commit with the changes")
|
||||
run_cmd_checked(["git", "add", "-A"]) # We can use -A since we checked the working dir is clean.
|
||||
run_cmd_checked(["git", "commit", "-m", f"Cut release {next_version_full}"])
|
||||
run_cmd_checked(["git", "add", CHANGELOG_FILE])
|
||||
run_cmd_checked(["git", "add", BUILDCONFIG_FILE])
|
||||
run_cmd_checked(["git", "commit", "-m", f"Cut release v{release_version}"])
|
||||
|
||||
response = input("Great! Would you like to push and open a pull-request? ([Y]/N)").lower()
|
||||
step_msg(f"Pushing {refs.release_pr}")
|
||||
|
||||
# 5. Create a PR to update main
|
||||
|
||||
step_msg(f"checkout {refs.main}")
|
||||
run_cmd_checked(["git", "checkout", refs.main])
|
||||
run_cmd_checked(["git", "checkout", "-b", refs.start_release_pr])
|
||||
|
||||
step_msg(f"UPDATING {CHANGELOG_FILE}")
|
||||
changelog[0:0] = [
|
||||
f"# v{major_version_number+1}.0 (In progress)",
|
||||
"",
|
||||
"[Full Changelog](In progress)",
|
||||
""
|
||||
]
|
||||
with open(CHANGELOG_FILE, "w") as stream:
|
||||
stream.write("\n".join(changelog))
|
||||
|
||||
step_msg(f"Creating a commit with the changes")
|
||||
run_cmd_checked(["git", "add", CHANGELOG_FILE])
|
||||
run_cmd_checked(["git", "commit", "-m", f"Start release v{major_version_number+1}"])
|
||||
|
||||
print()
|
||||
response = input("Great! Would you like to push and open the two pull-requests? ([Y]/N)").lower()
|
||||
if response != "y" and response != "" and response != "yes":
|
||||
exit(0)
|
||||
run_cmd_checked(["git", "push", remote, release_branch])
|
||||
if repo_owner == 'mozilla':
|
||||
webbrowser.open_new_tab(f"https://github.com/mozilla/application-services/compare/{base_branch}...{release_branch}")
|
||||
else:
|
||||
webbrowser.open_new_tab(f"https://github.com/mozilla/application-services/compare/{base_branch}...{repo_owner}:{release_branch}")
|
||||
|
||||
run_cmd_checked(["git", "push", moz_remote, refs.release_pr])
|
||||
run_cmd_checked(["git", "push", moz_remote, refs.start_release_pr])
|
||||
|
||||
webbrowser.open_new_tab(f"https://github.com/mozilla/application-services/compare/{refs.release}...{refs.release_pr}")
|
||||
webbrowser.open_new_tab(f"https://github.com/mozilla/application-services/compare/{refs.main}...{refs.start_release_pr}")
|
||||
run_cmd_checked(["git", "checkout", refs.main])
|
||||
|
|
|
|||
|
|
@ -1,6 +1,5 @@
|
|||
# Common code used by the automation python scripts.
|
||||
|
||||
import os
|
||||
import subprocess
|
||||
from pathlib import Path
|
||||
|
||||
|
|
@ -17,6 +16,10 @@ def run_cmd_checked(*args, **kwargs):
|
|||
kwargs["check"] = True
|
||||
return subprocess.run(*args, **kwargs)
|
||||
|
||||
def check_output(*args, **kwargs):
|
||||
"""Run a command, throwing an exception if it exits with non-zero status."""
|
||||
return subprocess.check_output(*args, **kwargs, encoding='utf8')
|
||||
|
||||
def ensure_working_tree_clean():
|
||||
"""Error out if there are un-committed or staged files in the working tree."""
|
||||
if run_cmd_checked(["git", "status", "--porcelain"], capture_output=True).stdout:
|
||||
|
|
@ -29,6 +32,19 @@ def find_app_services_root():
|
|||
cur_dir = cur_dir.parent
|
||||
return cur_dir.absolute()
|
||||
|
||||
def get_moz_remote():
|
||||
"""
|
||||
Get the name of the remote for the official mozilla application-services repo
|
||||
"""
|
||||
for line in check_output(["git", "remote", "-v"]).splitlines():
|
||||
split = line.split()
|
||||
if (len(split) == 3
|
||||
and split[1] == 'git@github.com:mozilla/application-services.git'
|
||||
and split[2] == '(push)'):
|
||||
return split[0]
|
||||
else:
|
||||
fatal_err("Can't find remote origin for git@github.com:mozilla/application-services.git")
|
||||
|
||||
def set_gradle_substitution_path(project_dir, name, value):
|
||||
"""Set a substitution path property in a gradle `local.properties` file.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,42 @@
|
|||
#!/usr/bin/env python3
|
||||
|
||||
# Purpose: Tag an Application-Services release
|
||||
# Dependencies: yaml
|
||||
# Usage: ./automation/tag-release.py [major-version-number]
|
||||
|
||||
import argparse
|
||||
import yaml
|
||||
|
||||
from shared import RefNames, get_moz_remote, step_msg, run_cmd_checked, check_output
|
||||
BUILDCONFIG_VERSION_FIELD = "libraryVersion"
|
||||
|
||||
parser = argparse.ArgumentParser(description="Tags an application-services release")
|
||||
parser.add_argument("major_version_number", type=int)
|
||||
args = parser.parse_args()
|
||||
moz_remote = get_moz_remote()
|
||||
major_version_number = args.major_version_number
|
||||
branch = RefNames(major_version_number, 0).release
|
||||
|
||||
step_msg(f"Getting version number")
|
||||
run_cmd_checked(["git", "fetch", moz_remote])
|
||||
build_config = yaml.safe_load(check_output([
|
||||
"git",
|
||||
"show",
|
||||
f"{moz_remote}/{branch}:.buildconfig-android.yml",
|
||||
]))
|
||||
version = build_config[BUILDCONFIG_VERSION_FIELD]
|
||||
tag = f"v{version}"
|
||||
|
||||
step_msg(f"Getting commit")
|
||||
commit = check_output(["git", "rev-parse", f"{moz_remote}/{branch}"]).strip()
|
||||
logline = check_output(["git", "log", "-n1", "--oneline", branch]).strip()
|
||||
|
||||
print(f"Branch: {branch}")
|
||||
print(f"Commit: {logline}")
|
||||
print(f"Tag: {tag}")
|
||||
response = input("Would you like to add the tag to the commit listed above? ([Y]/N)").lower()
|
||||
if response != "y" and response != "" and response != "yes":
|
||||
exit(0)
|
||||
|
||||
run_cmd_checked(["git", "tag", tag, commit])
|
||||
run_cmd_checked(["git", "push", moz_remote, tag])
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
This documents changes that were made to the nimbus-sdk before it was fully
|
||||
merged into the application-services repository. New entries should be added
|
||||
to the application-services repo CHANGES_UNRELEASED.md file, not here.
|
||||
to the application-services repo CHANGELOG.md file, not here.
|
||||
|
||||
# 0.10.0 (_2021-03-18_)
|
||||
## ⚠️ Breaking changes ⚠️
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Before submitting a PR:
|
|||
- Your code should pass all the automated tests before you submit your PR for review.
|
||||
- Before pushing your changes, run `./automation/tests.py changes`. The script will calculate which components were changed and run test suites, linters and formatters against those components. Because the script runs a limited set of tests, the script should execute in a fairly reasonable amount of time.
|
||||
- If you have modified any Swift code, also run `swiftformat --swiftversion 5` on the modified code.
|
||||
- Your patch should include a changelog entry in [CHANGES_UNRELEASED.md](https://github.com/mozilla/application-services/blob/main/CHANGES_UNRELEASED.md) or an explanation of why
|
||||
- Your patch should include a changelog entry in [CHANGELOG.md](https://github.com/mozilla/application-services/blob/main/CHANGELOG.md) or an explanation of why
|
||||
it does not need one. Any breaking changes to Swift or Kotlin binding APIs should be noted explicitly.
|
||||
- If your patch adds new dependencies, they must follow our [dependency management guidelines](./dependency-management.md).
|
||||
Please include a summary of the due diligence applied in selecting new dependencies.
|
||||
|
|
|
|||
|
|
@ -1,105 +0,0 @@
|
|||
# Application Services Release Process
|
||||
|
||||
## Make a new release from latest main.
|
||||
1. Create a release commit.
|
||||
- **Automated process:** run the `./automation/prepare-release.py` script to create a release commit and open a pull-request.
|
||||
|
||||
Note that after this script is executed, the following should be true:
|
||||
- The library version has been updated in `.buildconfig-android.yml`.
|
||||
- The entries in `CHANGES_UNRELEASED.md` have been moved to `CHANGELOG.md` under a header with the new version number and a link to the full changelog since the previous release.
|
||||
- The full changelog link in `CHANGES_UNRELEASED.md` has been updated with the new release version.
|
||||
|
||||
- **Manual process:** if the automated process above fails, refer to the [Create a release commit manually](#create-a-release-commit-manually) section.
|
||||
|
||||
**Note:** Because the release commit must be on the main branch, your PR will need to be approved, CI successful, and merged before a release can be cut.
|
||||
2. Cut the actual release.
|
||||
1. Click "Releases", and then "Draft a New Release" in the github UI.
|
||||
2. Enter `v<myversion>` as the tag. It's important this is the same as the tags that are in the changelog.
|
||||
3. Under the description, paste the contents of the release notes from CHANGELOG.md.
|
||||
4. Note that the release is not avaliable until the taskcluster build completes for that tag.
|
||||
- Finding this out takes a little navigation in the github UI. It's available at `https://github.com/mozilla/application-services/commits/v<VERSION NUMBER>` in the build status info (the emoji) next to the last commit.
|
||||
- If the taskcluster tag and/or release tasks fail, ping someone in slack and we'll figure out what to do.
|
||||
5. Click "Publish Release".
|
||||
3. Inform consumers that the new release is available so that [android-components](https://github.com/mozilla-mobile/android-components) can be updated. If you will be creating the update, do the following:
|
||||
1. If the changes expose new functionality, or otherwise require changes to code or documentation in https://github.com/mozilla-mobile/android-components, perform those. This part is often done at the same time as the changes in application-services, to avoid being blocked on steps 3-4 of this document.
|
||||
2. Change the versions of our dependencies in [buildSrc/src/main/java/Dependencies.kt](https://github.com/mozilla-mobile/android-components/blob/master/buildSrc/src/main/java/Dependencies.kt).
|
||||
3. Note the relevant changes in their [docs/changelog.md](https://github.com/mozilla-mobile/android-components/blob/master/docs/changelog.md), and update the application-services version there as well in their list of dependency versions.
|
||||
4. **_Important: Manually test the changes versus the samples in android-components._**
|
||||
- We do not have automated test coverage for much of the network functionality at this point, so this is crucial.
|
||||
- You can do this using the smoketest instructions below.
|
||||
**Note:** iOS smoke tests can only be run on macs.
|
||||
- Run the `./automation/smoke-test-android-components.py` script to test integration with Android Components.
|
||||
- Run the `./automation/smoke-test-fenix.py` script to test integration with Fenix.
|
||||
5. Get it PRed and landed.
|
||||
|
||||
**Note**: Before your release can be consumed by iOS, you will have to release [rust-components-swift](https://github.com/mozilla/rust-components-swift#cutting-a-new-release) too. There is automation that runs everyday to prepare a release PR, however, if your release is urgent run the job manually. You can run the job by:
|
||||
1. Navigating in [rust-component-swift's github](https://github.com/mozilla/rust-components-swift) to the `Actions` tab
|
||||
1. Clicking the `Create a PR for release with the newest A-S version available` GitHub action
|
||||
1. Click `run workflow` and base off the main branch
|
||||
1. The job will take a few minutes, but then will create a PR in `rust-components-swift`. Approve and merge the PR
|
||||
1. Cut a GitHub release using the GitHub UI with the tag in the form of `XX.YY.ZZ` (no `v` prefix)
|
||||
|
||||
**Note:** If you need to manually produce the iOS build for some reason (for example, if CircleCI cannot), someone with a mac needs to do the following steps:
|
||||
1. If necessary, set up for performing iOS builds using `./libs/verify-ios-environment.sh`.
|
||||
2. Run `./megazords/ios-rust/build-xcframework.sh`
|
||||
3. Upload the resulting `MozillaRustComponents.xcframework.zip` as an attachment on the github release.
|
||||
|
||||
---
|
||||
## Make a new point-release from an existing release that is behind latest main.
|
||||
|
||||
1. If necessary, make a new branch named `release-vXX` which will be used for all point-releases on the `vXX.YY.ZZ`
|
||||
series. Example:
|
||||
```
|
||||
git checkout -b release-v72 v72.1.0
|
||||
git push -u origin release-v72
|
||||
```
|
||||
2. Make a new branch with any fixes to be included in the release, *remembering not to make any breaking API changes.*. This may involve cherry-picking fixes from main, or developing a new fix directly against the branch. Example:
|
||||
```
|
||||
git checkout -b fixes-for-v72.1.1 release-v72
|
||||
git cherry-pick 37d35304a4d1d285c8f6f3ce3df3c412fcd2d6c6
|
||||
git push -u origin fixes-for-v72.1.1
|
||||
```
|
||||
3. Get a PR up with your changes and land them into the "base" branch.
|
||||
For example, if you are making a `release-v72.1.1` release, all the changes
|
||||
you want in that release must already be in the `release-v72` branch before
|
||||
following the steps below.
|
||||
4. Follow the above steps for cutting a new release from main, except that:
|
||||
* When running the `./automation/prepare-release.py` script, use the `--base-branch` argument to point it at your release branch, and specify `patch` as the release type. Example:
|
||||
```
|
||||
./automation/prepare-release.py --base-branch=release-v72 patch
|
||||
```
|
||||
* When opening a PR to land the commits, target the `release-vXX` branch rather than main.
|
||||
* When cutting the new release via github's UI, target the `release-vXX` branch rather than main.
|
||||
5. Merge the new release back to main.
|
||||
* This will typically require a PR and involve resolving merge conflicts in the changelog.
|
||||
* This ensures we do not accidentally orphan any fixes that were made directly against the release branch,
|
||||
and also helps ensure that every release has an easily-discoverable changelog entry in main.
|
||||
* When merging the PR, create a merge commit instead of squashing and merging. You can do this by choosing "Merge Pull Request" in GitHub's UI.
|
||||
* GitHub may require you to use admin privileges to merge the PR since the `release-vXX` branch is most likely not up to date with main. If there are no merge conflicts to resolve and CI checks pass, you can check the checkbox once the PR is approved.
|
||||
|
||||
---
|
||||
### Create a release commit manually
|
||||
|
||||
1. Update the changelog.
|
||||
1. Copy the contents from `CHANGES_UNRELEASED.md` into the top of `CHANGELOG.md`, except for the part that links to this document.
|
||||
2. In `CHANGELOG.md`:
|
||||
1. Replace `# Unreleased Changes` with `# v<new-version-number> (_<current date>_)`.
|
||||
2. Replace `main` in the Full Changelog link (which you pasted in from `CHANGES_UNRELEASED.md`) to be `v<new-version-number>`. E.g. if you are releasing 0.13.2, the link should be
|
||||
```
|
||||
[Full Changelog](https://github.com/mozilla/application-services/compare/v0.13.1...v0.13.2)
|
||||
```
|
||||
Note that this needs three dots (`...`) between the two tags (two dots is different). Yes, the second tag doesn't exist yet, you'll make it later.
|
||||
3. Optionally, go over the commits between the past release and this one and see if anything is worth including.
|
||||
4. Make sure the changelog follows the format of the other changelog entries. If you have access, [this document](https://docs.google.com/document/d/1oxdGm7OQcsy78NzXjMQKTbfzn21tl9Nopmvo8NCMWmU) is fairly comprehensive. For a concrete example, at the time of this writing, see the [0.13.0](https://github.com/mozilla/application-services/blob/main/CHANGELOG.md#0130-2019-01-09) release notes.
|
||||
- Note that we try to provide PR or issue numbers (and links) for each change. Please add these if they are missing.
|
||||
|
||||
3. In `CHANGES_UNRELEASED.md`:
|
||||
1. Delete the list of changes that are now in the changelog.
|
||||
2. Update the "Full Changelog" link so that it starts at your new version and continues to main. E.g. for 60.0.6 this would be
|
||||
```
|
||||
[Full Changelog](https://github.com/mozilla/application-services/compare/v60.0.6...main)
|
||||
```
|
||||
Again, this needs 3 dots.
|
||||
|
||||
2. Bump `libraryVersion` in the top-level [.buildconfig-android.yml](https://github.com/mozilla/application-services/blob/main/.buildconfig-android.yml) file. Be sure you're following semver, and if in doubt, ask.
|
||||
3. Land the commits that perform the steps above. This takes a PR, typically, because of branch protection on main.
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
# 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. Whenever a commit is pushed there,
|
||||
we build all artifacts needed for the release. Once we're ready to publish the release, we run the
|
||||
taskcluster release promotion action which signs and publishes the artifacts.
|
||||
|
||||
TODO: explain release-promotion more.
|
||||
|
||||
## What to do at the end of a nightly cycle
|
||||
|
||||
1. Start this 2 workdays before the nightly cycle ends
|
||||
|
||||
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 `.buildconfig-android.yml` like this:
|
||||
|
||||
```
|
||||
diff --git a/.buildconfig-android.yml b/.buildconfig-android.yml
|
||||
index 8cd923873..6482018e0 100644
|
||||
--- a/.buildconfig-android.yml
|
||||
+++ b/.buildconfig-android.yml
|
||||
@@ -1,4 +1,4 @@
|
||||
-libraryVersion: 114.0a1
|
||||
+libraryVersion: 114.0
|
||||
groupId: org.mozilla.appservices
|
||||
```
|
||||
|
||||
* Create a PR on `main` that starts a new CHANGELOG haeder.
|
||||
|
||||
3. Trigger release-promotion once the PRs are approved, merged, and CI has completed
|
||||
|
||||
* TODO: explain how to do this
|
||||
|
||||
4. Tag the release with `automation/tag-release.py [major-version-number]`
|
||||
|
||||
5. Update consumer applications
|
||||
* firefox-android: Create a PR that updates
|
||||
`android-components/plugins/dependencies/src/main/java/ApplicationServices.kt` following the
|
||||
directions in the [release checklist](https://github.com/mozilla-mobile/firefox-android/blob/main/docs/contribute/release_checklist.md)
|
||||
* firefox-ios: TODO
|
||||
|
||||
### Cutting patch releases for uplifted changes
|
||||
|
||||
If you want to uplift changes into the a previous release:
|
||||
|
||||
* Make sure the changes are present in `main` and have been thoroughly tested.
|
||||
* Checkout the `release-v114` branch
|
||||
* Bump `libraryVersion` in `build-config-android.yml`
|
||||
* Cherry-pick any commits that you want to uplift
|
||||
* Create a PR for the changes
|
||||
* Trigger release-promotion for the branch once the PRs are approved, merged, and CI has completed
|
||||
Загрузка…
Ссылка в новой задаче