Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump version codes for upcoming alpha releases, plus fix their order #4850

Closed
BenHenning opened this issue Jan 20, 2023 · 0 comments · Fixed by #4851
Closed

Bump version codes for upcoming alpha releases, plus fix their order #4850

BenHenning opened this issue Jan 20, 2023 · 0 comments · Fixed by #4851
Assignees

Comments

@BenHenning
Copy link
Member

This issue tracks two things:

  1. The version codes need to be incremented for the upcoming release of 0.10 alpha
  2. The version codes need to be ordered such that newer flavors take priority over older flavors (so that users get the alpha version of the app instead of beta for the same version name)
@BenHenning BenHenning self-assigned this Jan 20, 2023
seanlip pushed a commit that referenced this issue Mar 10, 2023
… code ordering (#4851)

## Explanation
Fixes #4850

This PR introduces the necessary version code updates for an upcoming
0.10 alpha release (2 different RCs). It also fixes the order of version
codes such that less stable versions of the app (i.e. build flavors)
take priority over more stable ones (so that users signed up for an
earlier pre-release will get that over later versions, e.g. users would
receive an alpha version of the app over beta if they're in both). This
happens because Play Store uses version codes as the actual comparable
versions for uploaded binaries, and it picks the binary with the highest
version code to be installed based on all that a user may qualify for
(based on which release tracks that they're participating in). The
assumption here is that newer versions maintain backward compatibility
with older versions, and this is something we will continue to aim for
(though with minimal guarantees for pre-release versions).

Note that one unfortunate side effect of this change is that local
installs of the app will require manually uninstalling when installing a
"more stable" build flavor (though technically this was an issue in the
other direction previously). This does make "upgrade" flows a little
trickier to test locally unless using pre-assembled binaries.

This PR also updates app versioning such that the version now includes
the local branch's commit rather than the common commit with develop (to
ensure RC rebuilds have properly unique version names rather than
sharing one version name for the release branch).

## Essential Checklist
- [x] The PR title and explanation each start with "Fix #bugnum: " (If
this PR fixes part of an issue, prefix the title with "Fix part of
#bugnum: ...".)
- [x] Any changes to
[scripts/assets](https://github.com/oppia/oppia-android/tree/develop/scripts/assets)
files have their rationale included in the PR explanation.
- [x] The PR follows the [style
guide](https://github.com/oppia/oppia-android/wiki/Coding-style-guide).
- [x] The PR does not contain any unnecessary code changes from Android
Studio
([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#undo-unnecessary-changes)).
- [x] The PR is made from a branch that's **not** called "develop" and
is up-to-date with "develop".
- [x] The PR is **assigned** to the appropriate reviewers
([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#clarification-regarding-assignees-and-reviewers-section)).

## For UI-specific PRs only
N/A -- This is an infrastructure-only change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants