Closed mattprecious closed 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?
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 inAUTO
. 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.
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.
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.
Ok, 3.8.1 should be out.
Thanks!
Describe the bug
In our Play Store listing we have released version codes:
3850000
3850001
(auto resolved using v3.7.0)3850002
(auto resolved using v3.7.0)3850003
(auto resolved using v3.7.0)3850004
(auto resolved using v3.7.0)We bumped the publisher plugin to v3.8.0, and attempted to publish
3850000
, again.This should have published version
3850005
, but it instead published7700004
, which is3850004 + 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