ReactiveCircus/streamlined

Question regarding version code and betas

Closed this issue · 2 comments

nilsi commented

Hi,

Using your app versioning library and really like it! Nicely done.
I'm debating what I should use as my version code and see that you use Instant.now().epochSecond.toInt() for this project. Have you experienced any problems with this approach? Any drawbacks.
Looks like a super simple and clean solution so I'm tempted to do the same.

Currently I construct my version name like this:

appVersioning {
  gitRootDirectory.set(rootProject.file("../"))

  overrideVersionCode { gitTag, providers, variantInfo ->
    Instant.now().epochSecond.intValue()
  }

  overrideVersionName { gitTag, providers, variantInfo ->
    def buildNumber = providers
      .environmentVariable("GITHUB_RUN_NUMBER")
      .getOrElse("0") as Integer

    def betaTag = "-beta${gitTag.commitsSinceLatestTag}"

    if (betaTag == "-beta0") {
      betaTag = ""
    }

    "${gitTag.rawTagName}$betaTag - #$buildNumber (${gitTag.commitHash})".toString()
  }
}

My plan is to name everything that has a commitsSinceLatestTag bigger than 0 a beta. (since then you are in between two releases)

And create a release by pushing a new version git tag to the main branch after merging the development branch.
I will set up my Github action workflow to react to tag pushes.

Does it sound like a good approach? I don't really have anyone to discuss this with currently so any feedback would be awesome.

ychescale9 commented

I'm debating what I should use as my version code and see that you use Instant.now().epochSecond.toInt() for this project. Have you experienced any problems with this approach? Any drawbacks.

I'm doing this at work and haven't run into any issues. The main drawback is you can't look at the version code and know the app version. You can use versionName but sometimes play console UI and firebase might show versionCode instead of versionName which can be slightly inconvenient.

The other thing to keep in mind is if you use timestamp as the versionCode, building from the same commit will produce different apk if there's no existing build cache. I haven't run into any issues with CI or debugging but you should make sure this is ok for your workflow.

Your plan sounds reasonable and is similar to what I do at work. If you don't have complex branching strategies in your release process and always release at the tip of main branches with feature flags, this approach should work well.

If you find anything missing or difficult to do with the app-versioning plugin feel free to creat an issue there:)

nilsi commented

That sounds promising. Thank you! It's always nice getting some confirmation that you are not totally off track :)

The plugin worked great so far!
The only problem I ran into was naming my APK with the version name. But I found the issue already created for that. As a workaround, I read from the version_name file and name the zip in the upload part of my workflow accordingly. I might add another build step later on where I also rename the APK after it's signed and ready. But it is not a big problem for now I would say, we can always figure out the version code and name with aapt dump badging if we need to.

This is how I name my APKs currently:

  android.applicationVariants.all { variant ->
    variant.outputs.all {
      def flavorName = variant.flavorName
      def buildType = variant.buildType.name

      outputFileName = "App-${flavorName}-${buildType}.apk"
    }
  }

I will let you know how it works in a while from now as I tested it out more.

  • 👍1