I am using Google play store Managed publishing feature. I have multiple app versions as below in the "Changes ready to publish" state in the Google Play console. I would like to only publish v6.6.1 as staged rollout, but I wonder if v6.6.0 will also be published when I publish the releases. I dont want v6.6.0 to be pubished, would prefer if it could be deleted but there was no way to remove an approved release.
Any assistance is much appreciated.
Option 1:
I think this could be done by going to Google Play Console and select App bundle explorer from the left menu.
then chose the App version 6.6.0 click on Upload new version
you should upload a version that is identical to the version previous to 6.6.0 but with same 6.6.0's version code & same version name (6.6.0).
Note: I've never tried this before, but I noticed it in the new Google Play Console.
Option 2:
upload a new version that is identical to the version previous to 6.6.0 but with new version code (highest version code, higher than 6.6.1 version code) and version name 6.5.9 (for example)
submit it as full roll-out
upload a new version that is identical to the version previous to 6.6.1 but with new version code (highest version code, higher than 6.5.9 version code) and version name 6.6.1 with Staged roll-out = 1%
Related
Google play has removed my app from production. I have made some changes and want to upload a new version to Internal testing.
In the Publishing overview section I can see both versions. The old version in the production and the new fixed version in internal testing.
I want to Send for review my new version, but I don't want to send my old version.
How to remove the old version from the Publishing overview? Can I specify to review only the new version?
You can promote your internal testing version to production with 1% users rollout. In that way, most users won't face the new version, and you will be able to override the old version review.
Steps:
go to Google Play console
select Internal testing from left menu
select Promote release dropdown menu
click on production
write "1" in rollout and release
I have contacted Google development support:
Unfortunately, we cannot deactivate the non-compliant version on your behalf. You will need to release a new compliant APK on the production track in order to deactivate the non-compliant APK. We apologize for the inconvenience this has caused.
I just upgraded from SonarQube 6.1 to 6.7.7. For SonarJava, it automatically installed 4.15.0.12310 (it was 4.10.0.10260 before). In the Marketplace, when I hover over the available versions from 5.0-5.13, it says “Incompatible”. When I hover over 5.13.1+, it says “Requires system update”. What does it mean for it to be incompatible if it doesn’t require a system update?
I am seeing this with various other plugins as well, such as SonarPython, which had 1.8 automatically installed. I had to manually install 1.9.1 in order to get this bug fix (which is why I originally upgraded the server): https://community.sonarsource.com/t/python-s1481-code-smell-unused-local-variables-should-be-removed-false-positive-with-string-interpolation/8961
I could manually install newer versions of other plugins as well, but I don’t know if that’s safe.
I also can’t find an official plugin compatibility matrix, since this only shows 7.9+: https://docs.sonarqube.org/latest/instance-administration/plugin-version-matrix/
Incompatible means that the plugin does not work with the version of SonarQube you have installed.
An example of an incompatible plugin would be one where the plugin relied on an API that was removed in your current SonarQube version. You may be able to use that version of the plugin if you downgraded your SonarQube instance to a previous version.
Requires system update means you need to upgrade SonarQube in order to install the plugin.
For what it's worth, the states as described by the API documentation are:
Update status values are:
COMPATIBLE: plugin is compatible with current SonarQube instance.
INCOMPATIBLE: plugin is not compatible with current SonarQube instance.
REQUIRES_SYSTEM_UPGRADE: plugin requires SonarQube to be upgraded before being installed.
DEPS_REQUIRE_SYSTEM_UPGRADE: at least one plugin on which the plugin is dependent requires SonarQube to be upgraded.
I have published two versions of my app apks to Google Play Console.(1.3, 1.4)
But later I realised that there is a minor issue in my newest version(1.4) that I have uploaded. So now I need to un-publish the newest version(1.4) and publish the older version(1.3) again.
How can I do that?
This was already answered here:
https://stackoverflow.com/a/29549730
It's not possible. You'll have to rebuild the older state and upload again under a new version number.
Well we released an update for our app last month, that set the minSDK to 5.0. We did this because we had a server side change that would break those on below 5.0.
Is there anyway to release another app on Google Play that would only be for user on below 5.0?
If we were to release the 5.0 and below version for a few days and then release the 5.0 and above. Will the 5.0 and below user still see that "slightly newer" below 5.0 release?
Yes. This is known as "multi-APK". See this help page.
You have two options for making sure users get the right APK.
the simplest to understand option is to set maxSdkVersion in the manifest of your pre-5.0 APK, and minSdkVersion in your manifest for the post 5.0 APK.
another option to use version code. Google Play will always deliver the highest version code that is compatible with a user. So if you make sure your pre-5.0 APK always has a lower version code than your post-5.0 APK, then both types of users will get the correct APK.
I ran into an issue today where my preview server was running an older version of a project instead of the most recently published version. The most recently published version was 1.0.4.10, but after some testing, I determined that version was not the version of the application that the server was retrieving.
After trying a few things, I tried publishing a new version under 1.0.5.0 instead of continuing with the 1.0.4.xx numbering, and that fixed the issue.
VS's auto increment feature recommended 1.0.4.10, but is there an issue with this being the same as 1.0.4.1? So maybe it was running 1.0.4.9? Or something behind the scenes I'm not aware of?