Mastodon/Tusky-App-Android
1
0
Fork 0
mirror of https://github.com/tuskyapp/Tusky synced 2024-12-22 23:08:04 +01:00
Code Issues Releases Wiki Activity

remove string check step from Release.md (#4196)

Browse Source 
It is no longer necessary since we have lint checks.
Also fixed some typos.
This commit is contained in:
Konrad Pozniak 2023-12-27 20:34:53 +01:00 committed by GitHub
parent af6b3a3a33
commit 7c5238a6bc
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 3 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
doc/Release.md
View File

@ -8,7 +8,6 @@ This approach of having ~500 user on the nightly releases and ~5000 users on the
- Make sure all new features are well tested by Nightly users and all issues addressed as good as possible. Check GitHub issues, Google Play crash reports, messages on `@Tusky@mastodon.social`, emails on `tusky@connyduck.at`, #Tusky hashtag.
- Merge the latest Weblate translations (Weblate -> Repository maintenance -> commit all changes, then merge the automatic PRs by @nailyk-weblate on GitHub)
- Check all the translations (Android Studio shows warnings on problems). Sometimes translators add faulty translations that would crash Tusky in this language, e.g. wrong number of formatting parameters. In this case it is usually easiest to just delete the string. [Example cleanup](https://github.com/tuskyapp/Tusky/commit/feaea70af418c77178985144a2d01a8e97725dfd).
- Update `versionCode` and `versionName` in `app/build.gradle`
- Add a new short changelog under `fastlane/metadata/android/en-US/changelogs`. Use the next versionCode as the filename. This is so translators on Weblate have the duration of the beta to translate the changelog and F-Droid users will see it in their language on the release. If another beta is released, the changelogs have to be renamed. Note that changelogs shouldn't be over 500 characters or F-Droid will truncate them.
- Merge `develop` into `main`
@ -37,13 +36,13 @@ This approach of having ~500 user on the nightly releases and ~5000 users on the
- Bitrise will automatically build and upload the release to the Internal Testing track on Google Play.
- Do a quick check to make sure the build doesn't crash, e.g. by enrolling yourself into the test track.
- In case there are any problems, delete the GitHub release, fix the problems and start again
- Download the build as apk from Google Play (App Bundle Explorer -> chose the release -> Downloads -> Signed, universal APK). Attach it to the GitHub Release.
- Download the build as apk from Google Play (App Bundle Explorer -> choose the release -> Downloads -> Signed, universal APK). Attach it to the GitHub Release.
- Create a new full release on Google Play. Reuse the build from the Internal Testing track.
- update the download link on the homepage ([repo](https://github.com/tuskyapp/tuskyapp.github.io))
- Update the download link on the homepage ([repo](https://github.com/tuskyapp/tuskyapp.github.io))
- Announce the release
## Versioning
Since Tusky is user facing software that has no Api, we don't use semantic versioning. Tusky verion numbers only consist of two numbers major.minor with optional commit hash (nightly/test releases) or beta flag (beta releases).
Since Tusky is user facing software that has no Api, we don't use semantic versioning. Tusky version numbers only consist of two numbers major.minor with optional commit hash (nightly/test releases) or beta flag (beta releases).
- User visible changes in the release -> new major version
- Only bugfixes, new translations, refactorings or performance improvements in the release -> new minor version