I am trying to update my app for the first time and ran into this issue. I searched a lot but none of the solutions worked for me.
App Store Connect Operation Error
ERROR ITMS-90062: "This bundle is invalid. The value for key CFBundleShortVersionString [2020.0] in the Info.plist file must contain a higher version than that of the previously approved version [2020.0]. Please find more information about CFBundleShortVersionString at https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring"
And my info.plist file is :
General Window:
TL;DR: If you have an app version that was approved for the official app store, you cannot upload a build with the same version to TestFlight. You have to remove the app from official app store submission, or increase your TestFlight version #.
I figured out why this happened to me.
I have an app in the app store with version 2010.
I have been running an external beta test with version 2020, and build numbers in the range of 400-410
In order to discover if my app would get rejected in the app store once I'm ready to actually release it in a few weeks, I submitted version 2020, build 407 for official app store review. I expected it to be rejected for various reasons. It was approved! However, i'm not ready to release it since I still have more fixes I want to implement. So, I let it sit there, waiting for me to do something with it.
Then, I wanted to upload a newer build for my External beta, still version 2020, build 410, and I received this error.
Thanks to user462990's answer, I realized that the error could be due to the fact that I have version 2020 currently approved and waiting to be launched into the official app store, so iTC didn't allow me to submit the same build # for a TestFlight external beta.
So, I selected "cancel this release" of the official approved version, and Viola! I can now upload a build with the same build #.
I think it was some issue on Apple's side. It resolved itself automatically after few hours.
What worked for me is to change it from 1.0 (.6) to 1.1 (.0) It's not really a new "Version" but incremental improvements and corrections. One thought is that when an app is accepted into the iTunes store then next upload must be to a higher VERSION.
You must always increase the version number when uploading updates, so change it from 1.0 to 1.1.
I'm having a similar issue today. I uploaded a new build a couple days ago with no issues. I found someone who posted a similar issue here: https://discussions.apple.com/thread/7297092. They were able to resolve it by changing the Info.plist values in their sub-projects, however, I tried doing that, and I still ran into the same issue.
I cannot find any information on why this is occurring or when this started, but I know that I uploaded a prerelease build to TestFlight with all of the same projects 5 days ago.
I currently increment my prerelease builds this:
1.10 (1) -> CFBundleVersionShortString (CFBundleVersion)
1.10 (2)
...
I was up to 1.10 (7), which I deployed 5 days ago. Now, I can't get anything to work 1.10 (8), 1.10 (9), 1.10 (1.10), etc. They all say "CFBundleShortVersionString [1.0] must be greater than previously approved version [1.3]"
1.3 is correct as the previous version available in the store, but clearly, 1.0 as the Bundle version is not.
I ran into this issue when going from version 1.141 to version 1.15. Apple does not treat the version as a decimal number - they treat it as multiple integers separated by periods. Thus in my case Apple considered 1.141 to be Major version 1, Minor version 141 and then my new version was Major version 1, Minor version 15. Since 141 > 15 it fails.
Two options to deal with this:
Use Apple's interpretation of version numbers, so you always increment the minor version by 1: 1.1, 1.2, ... 1.9, 1.10, 1.11.
If you wish to use "hundreds" or "thousands" places (I do, as I try to encode the scope of the build in the precision - I use the thousands place for minor bug fix releases), then always pad them out with zeros: 1.10, 1.11, 1.20, 1.30
So in my case I went from 1.141 to 1.150 and I was able to upload.
Related
In the given scenario, new Dev A has a new version of npm (8.3). He does a clone of the repo and npm says the package.lock file needs to be upgraded from lockFile version format 1 to version 2. Then he checks that in. So now the repo has a lock file with format version 2 and other devs pull that down.
Time goes by with no problems. Then Dev B, who's on version 6.13, installs a package. Is it normal that the lock file will change back to version one FROM version 2? In other words, each time a dev with a different version of npm that employs a different format, upgrades or installs a package, is it normal that it changes the lockfileVersion format over and over depending on their npm version and its format? Or should it stay with lockFileVersion 2?
Trying to identify what happened recently with our packages, and I'm looking to exclude this as a possible issue.
From what I read fileLockVersion 2 is supposed to be backwards compatible. But is it supposed to change back and forth like that? I wouldn't think so because how can someone with version 2 (Dev A) use version 1 if it was required to upgrade to version 2 in the first place?
So am I correct that once it's on version 2 it should stay that way? And if so, what would cause it to go back to version 1.
Thanks
No, it's not normal for developers to keep flipping versions like that, but it's fairly common for it to occur. We also had this happen specifically with package-lock.json so we told everyone to upgrade, and we made sure to upgrade all of our build agents. Similarly, in Visual Studio solutions some developers occasionally changed the version of VS back and forth from 2017 to 2019 a few times before we told everyone to just upgrade to 2019.
Generally it's best to avoid it if possible.
Some time after the release of Elm19 I published a library, which I needed for an Elm18 code base: thought2/elm-wikimedia-commons.
This worked well, it's listed in the community driven Elm18 package database: https://dmy.github.io/elm-0.18-packages/, can be installed and all good. Except the fact that the documentation is not shown in the package details, but that I heard is a known bug there. (But still I think this is very bad)
But the main problem is now, how to migrate the library to Elm 19: The actual migration steps are done and live in the master branch of the repo: http://github.com/thought2/elm-wikimedia-commons
The Elm18 versions proceeded to 1.1.0 in the meanwhile and after the migration there had to be done an API change, so I'd assume the latest version to become 2.0.0. If I add this to elm.json, the command elm publish tells me that this would be the first version and I should change this. Which is not right.
After a bit of research, I found out that the package (among other 18 ones that have been published in the same time period) is not listed in this json: https://package.elm-lang.org/all-packages This should contain all packages regardless of versions.
Any ideas what to do? This is really blocking my development, as I'm stuck in both lands now: 18 and 19. Would appreciate a lot if someone has some hints or solutions for me!
You shouldn't need to mess with the version number specified in elm.json.
If you set it back to the version of the package that is already published and run elm bump the elm program will look at the changes you've made to the package's API and set the new version accordingly.
Looking at https://github.com/thought2/elm-wikimedia-commons it doesn't look like any of your upgrade changes were breaking changes to your package API so the version won't be a 2.x.x, it will be a 1.x.x.
You'll need to remove the 2.0.0 git tag as well and instead add a tag for the version that elm bump tells you that your package is.
Our product version follows Semantic Versioning with an extra digit for build package identification:
major.minor.patch.build
The first 3 parts are for source code versioning, depending on API compatibility and bug fixes (patches). The last part is to keep track of multiple build packages. Multiple builds can happen with no source code changes (therefore no changes to major.minor.patch). Reasons for multiple builds are numerous all relating specifically to Android APK packaging (such Icons missing/changed, minSDKVersion increases, permission changes, SDK updates, descriptor-file changes [we are using AIR], etc)
Unfortunately, Google Play does not recognize this 4-part version. It only recognizes the first 3 parts. Example:
2.3.1.1 - Uploaded, received warning about SDK/API min version mismatch.
2.3.1.2 - No source code changes, only bumped minSDKVersion in manifest.
As far as Google Play is concerned, both are version 2.3.1 (2003001)
Why does it matter?
In order to test In-App-Billing (IAB) purchases, a version has to be published to Alpha (or Beta or Production). Once published, you cannot upload another APK without incrementing the version. As far as we are concerned, we are incrementing the version, but Google doesn't recognize that. For us, to bump the patch number when there were no source code changes is stupid and goes against the company versioning scheme which spans many more platforms then just Google Play.
So what to do for IAB testing?
- We distribute APKs to QA internally (not through Google Play), however we are still required to publish an APK to Alpha in order to test IAB.
- Without publishing an APK with increased version number, IAB testing errors out (APK version on device cannot be higher than the latest uploaded APK in Google Play)
How do others handle this?
The first version of our app 1.0.0 was uploaded and approved by Apple and currently, it has a status "Developer Removed From Sale". However this version has severals bugs and some features are missing, so we decided not to release it, to improve it and release another version.
So, we uploaded another version 1.1.0 after some time, and currently, it has "Pending Developer Release" status. The funny thing is managing guys decided to add yet another features, so we will have to upload the third version.
The question is will the second approved app version (1.1.0) be there after uploading the third version to itunes connect, or will it be deleted? We definitely don't need the first version because there are bugs but it's unable to delete it even if it was not released to app store. But I would prefer to have the second version until the third be approved (just in case).
The current approved version will remain Ready for Sale (wether you choose to put it live on the App Store by making in available in one, some or all countries or not) while the Update is Waiting for Review, In Review, and Processing for the App Store, and will be removed when the Update's status goes to Ready for Sale. (It will also remain should the Update be Rejected.)
With the new firefox we are shipping more and more libraries as the XPom interfaces we interact with are changing. We are at 10 dlls and increasing, each with a size of almost 2M.
This size is a concern for some users.
While we look at restructuring the library to seperate the parts we can make common between them, we are thinking about how we might reduce space on the disk while supporting version upgrades.
For instance, user has FireFox 3.6 and 4.0 installed and when our product is installed we install a dll for each version. When Firefox is 4.0 upgraded (say to 6.0) how might we now install from the msi the missing dll for 6.0 support.
Any ideas on how we could achieve this?
Are we worrying for no reason?
My first thought was we 'AllowAdvertise' and when FF tries to load the dll as directed by chrome it will cause the install, it doesn't seem to work.
My first reaction is to suggest that you move away from XPCOM and towards js-ctypes. After all, this is the direction that Mozilla is pushing extension developers (see Wladimir Palant's comments for example). If there isn't anything in your binary code that absolutely positively requires use of XPCOM, you'll be much happier to ship a DLL that interfaces with JS when needed via js-ctypes.
I guess that your extension is Windows-only so supporting multiple platforms is not an issue. A possible short-term solution:
Have a separate extension package for each Firefox version, mark it as compatible with this Firefox version only (e.g. minVersion 4.0 and maxVersion 4.*).
When your extension is installed, install the version that is compatible with user's installed Firefox version.
Make sure that your extensions have an updateURL entry that is pointing to your server. It is important to have %APP_VERSION% in the URL.
Make sure to test Firefox betas and prepare a new extension version in time for the next Firefox release (releases are scheduled on Tuesdays every 6 weeks, next release being on September 27th).
Configure your server to indicate different packages as updates depending on the Firefox version used. So an update check with %APP_VERSION% 4.0.1 would be sent to extension-ff4.xpi while %APP_VERSION% 6.0 would get extension-ff6.xpi.
Firefox will always check for extension updates when the application is updated. If you can give it a compatible update it will install it. But preparing new packages every six weeks requires tons of effort and I guess that you want to refactor your code/move to js-ctypes ASAP. Oh, and I think that you need to ignore the unlikely scenario that some user has more than one Firefox version installed.