Skip to content
Mike Hardy edited this page Feb 13, 2020 · 25 revisions

This page describes how to release AnkiDroid. It can be interesting as an insight to understand the project better, or to improve the procedure.

Development lifecycle

There are three main phases the project alternates between (alpha, beta, stable).

We use a simple branching model where "master" (the default branch) contains the latest (unstable) development code, which is where all merge requests should be submitted. Alphas a released from master during this phase.

When we move into the "beta" phase of the development cycle, we implement a feature freeze, and a temporary branch "release-N.n" (N.n being the version code) is created which is only for important bug fixes. During this period, important bug fixes are merged by the development team into "release-N.n" (see below).

If an urgent bug is discovered shortly after a major release, a special "hotfix-N.n" branch will be created from the tag from the latest stable release code found here.

Alpha or beta release procedure

  • Always use this repository: https://github.com/ankidroid/Anki-Android
  • Checkout the branch to release ("master" for an alpha, or for instance "release-2.9" or maybe "hotfix-2.9.4" for a beta)
  • In AndroidManifest.xml change android:versionName from 2.9beta11 to 2.9beta12 (for instance), and change android:versionCode accordingly.
    • As a special case, when creating a new hotfix branch (e.g., hotfix-2.9.4, you will start by calling your first beta hotfix-2.9.4beta0 with release version code ending 00 - the release script will bump those 0's to 1's for the first beta of the hotfix)
  • The tools/release.sh script will bump the versions, compile and upload to Google Play + Github and tag and push
    • The release script makes use of the github-release tool and gawk
    • As a special case, when creating a new release or hotfix branch, will have to set the branch (git push --set-upstream origin hotfix-2.9.4 for example) and then run git push --tags to get the new branch contents correct in github

Stable release procedure

Build

  • Update the changelog and/or the manual (in the docs repository) with notable changes
  • Always use this repository: https://github.com/ankidroid/Anki-Android
  • Switch to the branch to release, for instance "release-2.10" or "hotfix-2.9.4"
  • Run ./tools/release.sh public to compile/upload/tag and push to github and Play Console
  • After the release script is finished, the stable build will be in the beta channel. Manually promote it to production using the web interface of the Play Console

Google Play

Upload the APK to Google Play. Archive the previous APK from the "Active" section, then publish.

Title and Description for each language:

  • Title: docs/marketing/localized description/android-titles.txt
  • Description: docs/marketing/localized description
  • New feature list: Run tools/humanize-new-features.sh

Send an email to the mailing list announcing the new version, link to APK, new features, localizations, and thanking the developers, translators, testers.

Chrome Web Store

The following instructions are left for posterity, but after the 2.9alpha commit that converted AnkiDroid to AndroidX, Chrome Web Store uploads no longer seem possible.

This makes the new build available to Chromebook users that do not have access to the Play Store. You must be a member of the google group "AnkiDroid Web Store Publishers".

Merging new changes from master into a release or hotfix branch

The following procedure can be used to go through all of the new commits in the master branch, and choose one by one whether or not to merge them into a release branch. Commit messages including the tag @branch-specific (such as version bump commits generated by the release script) can be skipped automatically.

# One time setup.
git clone [email protected]:ankidroid/Anki-Android.git
cd Anki-Android

# Every time setup.
RELEASE_BRANCH=release-2.9  # Update this accordingly.
git fetch
git checkout master
git pull origin master --ff-only
git checkout $RELEASE_BRANCH
git pull origin $RELEASE_BRANCH --ff-only

# Pick one of the following to options:

# 1. Manual flow
./tools/gitflow-integrate  show master $RELEASE_BRANCH
# This will tell you what the tool will do by default, merge or skip.

# Decide which action to take:
# a. Default action (shown above).
./tools/gitflow-integrate apply master $RELEASE_BRANCH
# b. Force a merge.
./tools/gitflow-integrate  merge master $RELEASE_BRANCH
# c. Force a skip.
./tools/gitflow-integrate  skip master $RELEASE_BRANCH
# Skips should be applied to version number changes,
# release packaging changes (i.e., change to icons, commenting
# of logs, etc.), and cherry-picks from develop into a release
# branch.
#
# Repeat until nothing is left to merge.

# 2. Automated flow
while ./tools/gitflow-integrate apply master $RELEASE_BRANCH; do
   echo;
done
# Note that this will always just do the default action for every commit.
# If @branch-specific is set in all the right places (see above for the
# common types of commit that should be skipped) then things should
# just work.

# NOTE: If a merge conflict arises, you will get a message like:
#   Automatic merge failed; fix conflicts and then commit the result.
#   Please resolve conflict and press ENTER
# You should resolve the conflict and press ENTER to continue.
# Remember to add 
# Make sure things still build.
./gradlew clean assembleDebug

# Show / confirm the list of changes
git log --first-parent origin/$RELEASE_BRANCH..$RELEASE_BRANCH --format='%B' --reverse

# Push changes 
git push