|
|
In order to create a new release, a few tasks need to be fulfilled. We have a script automating this, but here's a high-level description of what has to be done.
|
|
|
|
|
|
## Compile the changelog
|
|
|
|
|
|
We use Towncrier to manage our changelog. Each closed issue should have a corresponding entry in the changes/changelog.d folder. Before releaseing the application, the changelog needs to be compiled:
|
|
|
|
|
|
`towncrier build --version <version>`
|
|
|
|
|
|
## Update static version definition for F-Droid
|
|
|
|
|
|
F-Droid needs a static version code and version name that can be parsed in order to detect updates of the app. This version number is managed in the file `fdroidversion.txt` in the project root folder.
|
|
|
|
|
|
### Version code
|
|
|
|
|
|
The format of the version code should follow this pattern:
|
|
|
|
|
|
1. A version format is supposed to look like this MAJOR.MINOR.PATCH, e.g. 1.2.3
|
|
|
2. Tokenize the version at the dot
|
|
|
3. Add trailing zeros for every token
|
|
|
4. Concat the tokens in the same order to a string and add 3 trailing zeroes
|
|
|
5. Strip leading zeros
|
|
|
|
|
|
Example: 1.2.3
|
|
|
Result: 102030000
|
|
|
|
|
|
Example: 0.1.0
|
|
|
Result: 1000000
|
|
|
|
|
|
### Version name
|
|
|
|
|
|
The version name is simple: Use the original version number and append `-fdroid`.
|
|
|
|
|
|
Example: 1.2.3
|
|
|
Result: 1.2.3-fdroid
|
|
|
|
|
|
## Tag the application
|
|
|
|
|
|
Create an (annotated) tag named after the original version number and push the tag. A release build will automatically be triggered for a new tag. |