This repository has been archived by the owner on Nov 16, 2023. It is now read-only.
versionCode was set incorrectly in v1.1.0 #21
Labels
bug
Something isn't working
status: resolved
This issue has been merged into main and deployed to canary.
Comments
ghost
added
the
2 tasks
dbjorge
added a commit
that referenced
this issue
Jun 3, 2020
…ionCode (#22) #### Description of changes This PR is a preventative measure to avoid the class of issue described by #21; it removes the human step of specifying an APK_VERSION_CODE from our release process by having the build infer it automatically from APK_VERSION_NAME. Once this PR is merged, I'll update the release validation template accordingly. Out of scope for this PR: implementing the logic #21 suggests for validating that versionName is newer than all previous releases. I verified manually that all of the error paths catch the issues that they're supposed to. [Example build with successful APK_VERSION_CODE inference](https://dev.azure.com/accessibility-insights-private/Accessibility%20Insights%20(private)/_build/results?buildId=11257&view=results) (you can verify that the correct versionCode is applied by examining the [log output](https://dev.azure.com/accessibility-insights-private/Accessibility%20Insights%20(private)/_build/results?buildId=11257&view=logs&j=ee97c5d1-e7c0-57b6-e379-76cd471b81bc&t=3d498509-f466-517e-a654-0f6cf997d88d&l=14) of the "print out generated release APK info" build step). #### Pull request checklist <!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox --> - [x] Addresses an existing issue: #21 - [n/a] Added/updated relevant unit test(s) - [n/a] Ran `./gradlew fastpass` from `AccessibilityInsightsForAndroidService` - [x] PR title _AND_ final merge commit title both start with a semantic tag (`fix:`, `chore:`, `feat(feature-name):`, `refactor:`).
dbjorge
added
the
status: resolved
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Describe the bug
Android uses an integer versionCode property as the means for APKs to specify to Android which version of an app they represent. Android requires that this versionCode increase when a new version is released; that's how it determines (either via the store or via adb) whether a new package represents an "upgrade" or a "downgrade".
We use semantic versioning with our releases for the versionName, and our release template defines a strategy for determining the versionCode from the versionName (for versionName xx.yy.zz, we use versionCode xxyyzz, ie, v1.1.0 should use versionCode 010100).
Unfortunately, right now our release process has humans hand-write the versionName and versionCode in our release build pipeline parameters, and the versionCode that was actually used in v1.1.0 was 011000, not 010100. This means that any future v1.1.1 through v1.10.0 would not end up increasing the versionCode if they were to release using the previous versionCode strategy.
This bug tracks both:
release-build.yaml, to prevent this specific problem from happening againrelease-build.yamlthat the version specified is greater than any previously released version, to prevent similar classes of issues from happening again (we need to do this manually since we aren't distributing through a store/package repository that enforces this on our behalf, like for most of our other projects)The text was updated successfully, but these errors were encountered: