Follow the steps in the checklist below to prepare a new release.
Release preparation checklist
Bump versions
All clients and server apps contain a version definition that needs to be updated with every release. This version is used for communication between components to ensure they are compatible with eachother. Versions are also used for official publication on the app stores.
For bumping the version for all projects in one go, you can use the interactive script located in:
./scripts/bump_version.sh
If you prefer to update versions manually instead of using the interactive script, see the Manual versioning page for detailed steps.
Write changelogs
When a new version of the mobile apps and/or browser extensions is released, write changelogs and commit them to:
- iOS app:
./fastlane/metadata/ios/en-US/changelogs/[versionCode].txt
.Filename should equal the
versionCode
in build.gradle. - Android app:
./fastlane/metadata/android/en-US/changelogs/[versionCode].txt
.Filename should equal the
versionCode
in build.gradle. - Browser extensions:
./fastlane/metadata/browser-extension/en-US/changelogs/[semver].txt
.Filename should equal the semver of the release (e.g.
0.20.0
).
Update documentation
- Update /docs instructions for any relevant changes to functionality or self-host installaton process
- Update README screenshots if applicable
- Update README current/upcoming features
Release flow
Follow the steps below to publish a new release to the various channels.
Create a new release on GitHub
The creation of the new release tag will cause the install.sh
script to see the new version via GitHub and prompt the user to update when install.sh update
is run.
- Create a new release on GitHub with a new tag in semver format, e.g.
0.12.0
. - Add a description to the release and generate the changelog.
- Publish the release.
Publish new Docker Images
The creation of the new release tag will automatically trigger the GitHub Actions workflow Publish Docker Images
which will build the docker images and push them to the GitHub Container Registry. After publishing, the images will then be available for the installation script to pull during the update. Do take note that this publish step may take up to 15 minutes to complete. Between the creation of the release tag and the completion of the publish step, the installation script will not be able to pull the new images (yet) and can throw errors, this is expected. After the publish is completed, users can update their self-hosted installation by following the update guide
Publish new browser extension version
The GitHub Actions workflow Browser Extension Build
will build the browser extension(s) and publish the archive to the GitHub Actions Artifacts page and also upload the archives to the release.
Note: this step is only required if the browser extension has been updated.
- Download the browser extension archives from the newly published release. Note: it can take a few minutes for the artifacts to be available after the release has been published.
- Upload the Chrome archive to the Chrome Web Store.
- Upload the Firefox archive (normal + sources) to the Firefox Add-ons page.
- Upload the Edge archive to the Microsoft Edge Add-ons page.
- Submit the Safari extension to Apple for review:
- Navigate to the
apps/browser-extension
directory. - Build the safari extension locally via
npm run build:safari
, which will output the build files todist/safari-mv2
. Note: it’s important to always rebuild, as otherwise stale build files from a previous build might get included in the Safari binary by accident! - Open the
apps/browser-extension/safari-xcode/AliasVault/AliasVault.xcodeproj
project in Xcode and submit the extension via the “Archive” and then “Distribute App” option.
- Navigate to the
Publish new Mobile App version
- Submit the iOS app to Apple for review:
- Open the
apps/mobile-app/ios/AliasVault.xcworkspace
project in Xcode and submit the extension via the “Archive” and then “Distribute App” option.
- Open the
- Submit the Android app to Google Play Console for review:
- Run the gradle build in the
apps/mobile-app/android
folder:./gradlew app:bundleRelease
- The resulting .aapb file will be available in the following location.
apps/mobile-ap/android/app/build/outputs/bundle/release
- Take this file and upload it to the Google Play Console.
- Run the gradle build in the