search

Triple-T / gradle-play-publisher

GPP is Android's unofficial release automation Gradle Plugin. It can do anything from building, uploading, and then promoting your App Bundle or APK to publishing app listings and other metadata.
MIT License
4.1k stars 339 forks source link

Version code was doubled using auto resolution #1077

Closed mattprecious closed 1 year ago

mattprecious commented 1 year ago

Describe the bug

In our Play Store listing we have released version codes:

We bumped the publisher plugin to v3.8.0, and attempted to publish 3850000, again.

This should have published version 3850005, but it instead published 7700004, which is 3850004 + 3850000.

How To Reproduce

Versions

Gradle Play Publisher: 3.8.0

Tasks executed

publishInternalReleaseBundle

Additional context (if a crash, provide stack trace)

I think it's this line here: https://github.com/Triple-T/gradle-play-publisher/blob/eeee0dc1ffa070ba9709b8a7d000912db15a3e04/play/plugin/src/main/kotlin/com/github/triplet/gradle/play/tasks/ProcessArtifactVersionCodes.kt#L54

Introduced in https://github.com/Triple-T/gradle-play-publisher/commit/0601633354c342eff7efa2f205f4db404ebe5c67

SUPERCILEX commented 1 year ago

Apologies for the inconvenience, I wasn't sure if anyone was actually relying on that behavior but clearly people are. I haven't really announced 3.8.0 yet so I'd consider patching that change out and making a 3.8.1... How hard would it be to change your default version codes to start at X and be the offsets you're looking for? This change was made so that manual publishing becomes possible by setting all your version codes to something higher than what's on the play store.

I'm guessing 3850000 is generated from some 3.85 git tag? I think you'd instead have to generate the default version code as the diff between the current git tag and the previous (so (385-384)*10_000). That might be a PitA.

Thinking about this a bit more, I wonder if we should just have another resolution strategy (maybe AUTO_OFFSET) that's does the dumb behavior and keep 3.7.0 behavior in AUTO. Thoughts?

mattprecious commented 1 year ago

How hard would it be to change your default version codes to start at X and be the offsets you're looking for?

I'm not sure what you mean by "default version codes". Is this a configuration of the plugin? I've scanned through the readme and nothing caught my eye.

I'm guessing 3850000 is generated from some 3.85 git tag? I think you'd instead have to generate the default version code as the diff between the current git tag and the previous (so (385-384)*10_000). That might be a PitA.

It's generated by concatenating 4 different version numbers: major, minor, patch, build. We manually bump major, minor, and patch through commits to our build.gradle, and release those manually to the Play Store. We have this plugin running for our internal nightly and were relying on the resolution strategy to walk up the patch versions for us.

Thinking about this a bit more, I wonder if we should just have another resolution strategy (maybe AUTO_OFFSET) that's does the dumb behavior and keep 3.7.0 behavior in AUTO. Thoughts?

This is a pretty major change so I would definitely vote for keeping the 3.7.0 behavior of AUTO! Changing version code behavior is pretty scary, IMO. Wouldn't want someone to accidentally lose a whole bunch of version code room.

SUPERCILEX commented 1 year ago

I'm not sure what you mean by "default version codes". Is this a configuration of the plugin? I've scanned through the readme and nothing caught my eye.

No, sorry I mean wherever you're setting the versionCode in your build script.

Wouldn't want someone to accidentally lose a whole bunch of version code room.

Ah crap, yeah that would suck. I'll just do the extra auto mode thing. Should be quick.

mattprecious commented 1 year ago

I'm not sure what you mean by "default version codes". Is this a configuration of the plugin? I've scanned through the readme and nothing caught my eye.

No, sorry I mean wherever you're setting the versionCode in your build script.

Ah, got it. I'm trying to understand then when default + maxVersionCode is a desirable resolution strategy. It seems like it would only really be desired if default = 1? Any other value and it makes large steps when there's a conflict, as seen here.

SUPERCILEX commented 1 year ago

Ok, 3.8.1 should be out.

mattprecious commented 1 year ago

Thanks!