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?
Related
I have various groups for test flight:
1) Internal Testers
2) Employees
3) Beta Testers
We first distribute to all devs via Internal Testers, once we believe it is stable enough, we release to the entire company for further testing and notes, which is Employees, and finally we release to all of our Beta Testers.
It would be very nice however, to be able to alternate between versions, e.g. say the latest version 7, which is for Internal Testers, fixed a lot of bugs, e.g. validations, but unknowingly, version 6 is broken for Employees and Beta Testers. Is it possible, if you are part of the Internal Testers that are testing version 7, to revert/test version 6 and see if these changes had any breaking changes?
Yes, in the TestFlight App, tap on the app icon and then select "Previous Builds".
You will then see a list of previous versions that you have been given access to test. Select the relevant version and then select "install" next to the build of that version that you wish to install.
If you have a known "bad build" you can expire it from the TestFlight page in AppStoreConnect to prevent it from being re-installed.
I have a problem with automated build distribution thru Fabric Beta with concurrent uploading.
For example I starting upload of first build and 5 seconds after it I starting upload second one. But because Internet is a magic-unstable-box the second build have uploads before the first build. And it's treated as first build is newer then second. But it's not true.
So I want to discard older (first) build when I uploading newer one.
Or I want some other workaround for my situation.
Mike from Fabric here. There is not an automated way within Fabric to stop the upload once it's started. You can manually remove versions via the app's settings page. From the documentation:
To remove, a specific version of your app, head to your app’s settings. Select the app whose name you want to change and click on the “Versions” button. After that, select the toggle on any build or version you want to disable. Disabling a version prevents new crash reports from flowing in, hides it from the version filter, and prevents beta testers from installing that version.
I set up my development environment to learn Starling today. I watched the video at Starling Tutorial Video 1 on YouTube, and I followed the steps. Toward the end of the video, the presenter notes that I should make sure there are no errors and run my program.
The assumption is that "make sure there are no errors" applies to the code that we have just written. I have no errors in the two files that I created along with the video instructor. However, I have 54 errors that exist within the newly installed Starling framework, which I am not yet experienced enough to debug and correct (see image).
The package that I installed for Starling is the latest release available from their website on the main page. I am using Flash Builder as recommended by their tutorial, and, clearly Flash has been advanced several generations since the tutorial was first created.
Is there a place where I can download a copy of Starling that has been upgraded to match the current version of flash and uses the correct ActiveScript 3 syntax?
Alternatively, are there any recommendations for bypassing or overlooking errors in a code base that is not mine to maintain?
Any help provided is appreciated. The screenshot below shows the 54 errors in the Starling packages.
Note: Most of the errors seem to regard Context3D objects. And I believe all instances of the errors regard "possibly undefined methods" being used, or an "possibly undefined property" being accessed.
Found some helpful resources:
Bulletin Board Discussion
Instructions for Installing Air SDK that are better than the YouTube video
I had to install the playerglobal.swc files and Air SDK multiple times. Eventually, I deleted all 11.1 folders to remove any potential conflicts.
On the last attempt to recreate the project, I noticed that the swc files were being loaded from the eclipse folder. The playerglobal.swc file was updated there, because I replaced ALL playerglobal.swc files. However, this copy of the Air SDK was not the latest release that I had installed.
I carefully matched each file loaded in the eclipse folder to the corresponding files in the '4.6.0 air 3.4' folder.
Once I did this, the compiler errors went away. Now I am getting ReferenceErrors during the build process, but that is a separate issue and unrelated to the above question.
Advice to those who follow:
Make sure, when you create your new Action Script project, that you load the swc files from the 4.6.0 folder or the 4.6.0 folder that you merged with the AIR SDK.
Save yourself some time and reduce risk of errors by using the ditto command to merge the AIR SDK into the 4.6.0 folder.
If you are still having trouble, delete references to old code-base versions to prevent any chance of accidental references being used.
What are the differences between aspnetcidev and aspnetvnext?
I see that aspnetcidev says "quick builds", but what does this mean?
Jan 29, 2016 edit:
This information is now part of the ASP.NET wiki: https://github.com/aspnet/Home/wiki/NuGet-feeds
The ASP.NET build system uses 3 myget feeds for each branch + nuget.org.
aspnetvolatile<branch> (aspnetvolatiledev/aspnetvolatilerelease)
aspnetci<branch> (aspnetcidev/aspnetcirelease)
aspnetvnext (dev branch)/aspnetrelease (release branch)
After each repo under github.com/aspnet builds successfully, each package produced by it is pushed to the corresponding volatile feed.
After the graph of repos is build, we trigger the Coherence build. This build verifies that the packages have matching versions and their references are correct (that they are coherent). Then, it pushes them to aspnetci<branch>.
Once the Coherence build passes, we run all our tests on the packages in the aspnetci<branch> feed. If the tests pass, we sign the packages and ship them to aspnetvnext or aspnetrelease
So the differences are:
aspnetvolatile<branch>
latest packages
possible not coherent
not tested
not signed
updated on every checkin
mostly used to diagnose build failure
aspnetci<branch>
possible not latest
coherent
not tested
not signed
updated when all repos build successfully
used by our build system
aspnetvnext/ (aspnetrelease|nuget.org)
possible not latest
coherent
signed
tested
updated when everything works
used for stable packages
Once the aspnetcirelease feed is stable, we push the packages from it to nuget.org.
Unless you work on developing new features for ASP.NET, I recommend that you use aspnetvnext (for dev bits) or nuget.org (for release bits). The release feed (aspnetrelease) is just a staging feed and it's not always in a good shape.
Edit:
I think it's easier to understand from a table:
I'm abrade that you can get the exact answer on the question only from Microsoft. You can open https://www.myget.org/gallery and filter for "aspnet" for example and will find many other repositories published for different teams.
For me more interesting is the information displayed by .NET Version Manager: dnvm (without parameters):
Thus, for me, the source https://www.myget.org/F/aspnetvnext/api/v2/ (or https://www.myget.org/F/aspnetvnext/api/v3/index.json) is the "official" place for the night builds of ASP.NET 5.
On the other side by filtering of https://www.myget.org/gallery "aspnet" you can see that aspnetvnext contains more distinct packages as aspnetcidev.
It's clear that both repositories probably contains different set of packages.
One important example where the repository https://www.myget.org/gallery/aspnetcidev be used is the new .NET Command Line Interface (.NET CLI) which you find on GitHub here. The new dotnet utility uses https://www.myget.org/F/aspnetcidev/api/v3/index.json together with many other sources in https://github.com/dotnet/cli/blob/master/NuGet.Config.
I suppose that AspNetCIDev is the repository of packages required for .NET CLI. It's the utility, which should replace dnx and dnu in RC2 of ASP.NET 5. See the post, this one and some other.
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.