The first version of my extension that I published to the Chrome Web Store was not 1 or 0.1 as initially users were manually installing it. How can I find out which was the first version that was published to the store?
I can't see previous versions in the developer dashboard. "Stats" shows installs over time but not which version they were.
You can see a list of published versions for an extension on https://chrome-stats.com/. Just search for the extension and click on the Download tab. It should have all versions within the past 2 years.
Related
Delete this threat if there is already one existing but I didn’t find it with the search function or it didn't help me out.
I tried to upload an update of my app.
I have an issue uploading on play console
My abb version that's currently online is called 113.
Now I want to make an update that's called 114
But I want to include version 113
Here is what the console gives me as error
This APK will not be served to any users because it is completely shadowed by one or more APKs with higher version codes. Remove this APK from your release or review the targeting and version codes of the APKs that you are including in this release.
I saw this errors in boards but the solutions there didn't help me since I work with App Bundles and not APKs
I found some bugs in my code and need to submit a new version.
How do I remove or cancel the old version that is in review in Google Play Console?
I am hoping to not waste Google's time to review something that is already outdated.
[Screenshot of the Issue]
I got the same issue you got when uploading two releases at the same time which both of them were in review mode, the simple answer is "You don't have to worry, the latest version uploaded will get published on Google Play"
You cannot remove versions of your app that you have published on the Google Play console. You can only halt releases for ones that have only been partially rolled out.
Instead, just submit the new version on the track and it will override the version that is in review. As it has a higher version code so it will replace the old version after it has been reviewed and users will download the new version.
I have a published Google Slides Addon via the G Suite Marketplace SDK. After following the publishing guide everything looked great, until I wanted to bump the version number in the Google Cloud Console via my project's G Suite Market Place SDK Configuration tab.
I entered the number and hit "Save Changes", which put the new version life right away. However, it appears that a couple hours it will always be reset to the same old version (7 in my case). I bumped it again three times and have already tried to update the Chrome Webstore Draft, but it keeps being reset.
Checking the docs, I see no further steps required. I have also not found out yet when the reset occurs, it appears to be "over night" from a European timezone.
EDIT: what may also be relevant, the version in the Google Cloud Console does not automatically update when I publish to the Chrome Webstore. Instead, I manually put the newest version.
This issue should be fixed now.
Also the new publishing flow for GSM, which no longer requires to publish or do changes in the Chrome Web Store, is now live.
I see each cfx tools always produce xpi with its own minVersion and maxVersion. However, those are limited to the versions which the SDK is compatible with, e.g. SDK 1.14 only for FF 21 - 25.0a1 , SDK 1.17 only for FF 26 - 30. My questions are:
Do I need to package my extension with new SDK everytime new version comes out ?
How do I maintain and update my extension in the future? Does Addon Developer Hub provides a way to submit the same extension for multiple SDK versions ? I tried to look around but couldn't find a way to submit multiple versions.
I want to make FF 21 as the minimum version, since that's the version which has SDK built-in. My extension currently compiles with both SDK 1.14 and SDK 1.17 with only cosmetic(syntax) adjustment.
The developer hub lets you choose which versions of Firefox the add-on is compatible with. This is just a GUI for setting the minVersion and maxVersion in the install.rdf. As long as you don't use modules or methods that require Firefox 22+, it shouldn't matter which version of the SDK you use, as the version of the SDK being run is determined by the version on your user's browser.
It's hard to find module specific compatibility (you can always go to the docs for the specific module and look at the edit history), but have a look at the SDK API Lifecycle to understand which modules can be used. Some notable example are:
The new UI modules require FF29 and some of their features require FF30.
The widget module is deprecated from FF 29 onwards, being replaced by the above.
One way to handle the above for backward compatibility is to do the following:
const { version } = require('sdk/system/xul-app');
if (version < 29) var widget = require("sdk/widget").Widget({...});
else var button = require("sdk/ui/button/action")({...});
So, to be clear:
It doesn't matter which version of the SDK you use unless you want to use new modules.
No, you shouldn't make multiple versions of your add-on. If you want to use new modules for new browsers, follow the code example above.
It's true that you must use valid existing application versions but you generally don't need to repackage your addons, unless of course a change in the SDK directly affects your addons.
The reason for this is that by default the max target version is not going to be checked.
From the install manifest documentation:
strictCompatibility
A Boolean value indicating if the add-on should be enabled when the version of the application is greater than its max version. By default, the value of this property is false meaning that the compatibility checking will not be performed against the max version.
<em:strictCompatibility>true</em:strictCompatibility>
Usually, there is no need to restrict the compatibility: not all new releases will break your extension and, if it is hosted on AMO, you'll get notice several weeks in advance if a potential risk has been detected. Moreover, an extension being disabled, even for a short period, leads to a bad experience for the user. About the only time you should need to set this if your add-on does things that are likely to be broken by Firefox updates. You do not need to set this flag if your add-on has a binary component, since add-ons with binary components are always subject to strict compatibility checking (because binary components need to be rebuilt for every major application release anyway).
There is also is a recommendation for choosing version ranges.
minVersion and maxVersion should specify the range of versions of the application you have tested with. In particular you should never specify a maxVersion that is larger than the currently available version of the application since you do not know what API and UI changes are just around the corner. With compatibility updating it is not necessary to release a whole new version of the extension just to increase its maxVersion.
Technically you can use wildcards, but the documentation mentions several times that AMO verifies and possibly rejects addons with incorrect versions.
I'm new to Firefox extension development, friendly speaking it's first day, I had followed the following article in order to start with Firefox extension development: How to develop a Firefox extension.
If I download the example from above given link's tutorial and try to install, it is installed perfectly but, when I update that example (just updating its name to the new extension name, where it is necessary in all files), and then install, I get the following message: "X could not be installed because it is not compatible with Firefox 15.0.1." (where X is the name of my extension).
Strange behavior same code one is installing fine and other one giving error.
Any idea where it is going wrong and what is causing this?
The problem is that you forgot to adjust the compatibility range in install.rdf so em:maxVersion is still saying 3.1b2 (meaning Firefox 3.1b2 - a rather old version). You should change that into 15.* if you want to support the current stable Firefox version or 16.* if you want to support the current beta versions. You can also change em:minVersion into something more meaningful: I doubt that you will verify whether your extension still works with Firefox 2.0.
As to why the extension installs if you don't change the extension ID, this is more complicated. First of all, there is a soft override mechanism for the compatibility ranges which allows extension authors to change the compatible version range without releasing a new version. In this particular case Firefox will check for extension updates by requesting this address or a similar one. The update server tells it that version 1.0 is still current but adjusts maxVersion to Firefox 8.0 - this value will override whatever is specified in install.rdf.
But that's not the end of the story. The compatibility check mechanism was changed significantly in Firefox 10, the default assumption is now that the add-on is compatible with newer versions even if that isn't specified explicitly anywhere. The requirements are that the extension doesn't opt out of lax compatibility checking, doesn't contain binary components and is compatible with at least Firefox 4. The original extension is compatible with Firefox 8 thanks to the soft override, with a different extension ID it is only compatible with Firefox 3.1b2 however (it isn't hosted on addons.mozilla.org so the update server doesn't know about it) which means that the lax compatibility checking doesn't apply to it.
For reference: the behavior described in the previous paragraph is controlled by the extensions.strictCompatibility, extensions.minCompatibleAppVersion and extensions.minCompatiblePlatformVersion preferences.