[Release] Element Android v1.4.31

Release checklist

Before the release

• Weblate sync, fix lint issue if any (in a dedicated PR)
• Check the update of the store descriptions (using Google Translate if necessary) to ensure that the changes are acceptable to be published to the stores.
• While Weblate is locked, and after the PR from Weblate has been merged, handle all the TODOs in the main strings.xml file
• Run the script ./tools/release/pushPlayStoreMetaData.sh. You can check in the GooglePlay console the Activity log to check the effect.

Do the release

• Make sure develop and main are up to date (git pull)
• Checkout develop and create a release with gitflow, branch name release/1.2.3
• Check the crashes from the PlayStore
• Check the rageshake with the current dev version: https://github.com/matrix-org/element-android-rageshakes/labels/1.2.3-dev
• Run the integration test, and especially UiAllScreensSanityTest.allScreensTest()
• Create an account on matrix.org and do some smoke tests that the sanity test does not cover like: 1-1 call, 1-1 video call, Jitsi call for instance
• Run towncrier: towncrier build --version v1.2.3 --draft (remove --draft do write the file CHANGES.md)
• Check that the folder changelog.d is empty. It can happen that some remaining files stay here
• Check the file CHANGES.md consistency. It’s possible to reorder items (most important changes first) or change their section if relevant. Also an opportunity to fix some typo, or rewrite things
• Add file for fastlane under ./fastlane/metadata/android/en-US/changelogs
• (optional) Push the branch and start a draft PR (will not be merged), to check that the CI is happy with all the changes.
• Finish release with gitflow, delete the draft PR (if created)
• Push main and the new tag v1.2.3 to origin
• Checkout develop
• Increase version (versionPatch + 2) in ./vector/build.gradle
• Change the value of SDK_VERSION in the file ./matrix-sdk-android/build.gradle
• Commit and push develop
• Wait for Buildkite to build the main branch.
• Run the script ~/scripts/releaseElement.sh. It will download the APKs from Buildkite check them and sign them.
• Install the APK on your phone to check that the upgrade went well (no init sync, etc.)
• Create the release on gitHub from the tag, copy paste the block from the file CHANGES.md
• Add the 4 signed APKs to the GitHub release
• Ping the Android Internal room

Once tested and validated internally

• Create a new open testing release on the GooglePlay console and upload the 4 signed Apks.
• Check that the version codes are correct
• Copy the fastlane change to the GooglePlay console in the section en-GB.
• Push the open testing release to 100% of the users
• Notify the F-Droid team here so that they can schedule the publication on F-Droid
• The application is available to the PlayStore testers (live). Google can take between 1 hour and up to 7 days to approve the release.
• The application is available to the F-Droid users.

Once open testing is live on PlayStore

• Ping the Android public room and update its topic

Once Live on F-Droid

• Update the Android public room topic

After at least 2 days (generally next Monday)

• Check the rageshakes
• Check the crash reports on the GooglePlay console
• Check the Android Element room for any reported issues on the new version
• If all is OK, promote the open testing release to production. Generally using a 100% roll out, but can be a smaller value depending on the release content.
• The application is available to the PlayStore users (live). Google can take (again!) between 1 hour and up to 7 days to approve the release.

Once production is live on PlayStore

• Ping the Android public room and update its topic
• Add an entry in the internal diary

Android SDK2

The SDK2 and the sample app are released only when Element has been pushed to production.

• Checkout the main branch on Element Android project

On the SDK2 project

https://github.com/matrix-org/matrix-android-sdk2

• Create a release with GitFlow
• Update the value of VERSION_NAME in the file gradle.properties
• Update the files ./build.gradle and ./gradle/gradle-wrapper.properties manually, to use the latest version for the dependency. You can get inspired by the same files on Element Android project.
• Run the script ./tools/import_from_element.sh
• Check the diff in the file ./matrix-sdk-android/build.gradle and restore what may have been erased (in particular the line apply plugin: "com.vanniktech.maven.publish" and the line about the version)
• Let the script finish to build the library
• Update the file CHANGES.md
• Finish the release using GitFlow
• Push the branch main, the new tag and the branch develop to origin

Release on MavenCentral

• Checkout the branch main
• Run the command ./gradlew publish --no-daemon --no-parallel. You’ll need some non-public element to do so
• Run the command ./gradlew closeAndReleaseRepository. If it is working well, you can jump directly to the final step of this section.

If ./gradlew closeAndReleaseRepository fails (for instance, several repositories are waiting to be handled), you have to close and release the repository manually. Do the following steps:

• Connect to https://s01.oss.sonatype.org
• Click on Staging Repositories and check the the files have been uploaded
• Click on close
• Wait (check Activity tab until step “Repository closed” is displayed)
• Click on release. The staging repository will disappear

Final step

• Check that the release is available in https://repo1.maven.org/maven2/org/matrix/android/matrix-android-sdk2/ (it can take a few minutes)

Release on GitHub

• Create the release on GitHub from the tag
• Upload the AAR on the GitHub release

Android SDK2 sample

https://github.com/matrix-org/matrix-android-sdk2-sample

• Update the dependency to the new version of the SDK2. It can take a few minutes for MavenCentral to make the library available. You can check status on https://repo1.maven.org/maven2/org/matrix/android/matrix-android-sdk2/
• Build and run the sample, you may have to fix some API break
• Commit and push directly on main

[opusforlife2]

@ouchadam I agree with bigCrash. F-Droid users got version 1.4.25 on 3 July. If you give the go ahead for 1.4.31 to be built, we could have it on F-Droid within 2-3 days.

But if we wait for 1.4.32 to complete the release cycle, that’s around 2 more weeks, making it almost 2 months since the last update, not to mention the possibility of hotfixes, which delay F-Droid deployment further.

Since 1.4.32 isn’t a hotfix, that means 1.4.31 is a good stable version for F-Droid to deploy.

[ouchadam]

1.4.32 isn’t a hotfix but it is almost entirely bug/crash fixes for issues introduced between 1.4.27 and 1.4.31

I would argue for avoiding introducing known (and fixed) crashes for the gain of 2-3 days of a recent version (the typical time it takes to generate a release and submit to the stores).

I do admit that the release process around Fdroid needs improving, especially around the communication from our side, that’s on me for these recent releases.