I built an app with
version: 2.0.2+20
in the pubspec.yaml
and everything (distribution and GooglePlay) worked.
Changing it to
version: 2.0.3+1
I get the error in the Goolge Play Console
Version code 1 has already been used. Try another version code.
I thought I can have a release "2.0.1+1" and later "2.0.2+1" and so on. Am I wrong? And if not - what couöd cause my problem?
You should increment version code always as it is used to identify and push updates internally. You can use any version name which is shown on the play store listing but must increment the number following the plus sign, that is version code.
version: 2.0.3+21
+20 and +1 at the end of your version represent the build number, 2.0.x is the build name.
What you need is to keep incrementing the build number (+1, +2, +3...) which each deploy to the stores.
And then use the first part x.x.x (2.0.3 for example) for naming the version you are trying to deploy.
The version code is two different numbers.
For exemple, in 2.0.2+20, 2.0.2 and 20 are two different parts.
Google Play uses the 20, so you must always increment it.
Related
I get so many frustrations with Azure DevOps. In my Build number format I would like to have both
A number that restart to 0 when I update my major an minor version.
But I also would like to have a real build number that is never reset whatever is my build number format. This build number can also be shared by all my build pipeline of my project. Is it possible?
I'm not using YAML format. I use the classic interfaces with the option page to set my build format. At this moment I have this:
It work except each month the r number restart at 0. I want it to continue.
EDIT
I still didn't decided my final format. I would like to understand all the possibilities. Now I discovered the $(BuildID) property I have another question. Is it possible to have something similar to $(Rev:r) variable but that only check the left part of my build number.
Example:
4.16.$(SequenceFor[4.16]).$(BuildID)
In fact I would like to manually set the Major and Minor version and let the system update one by one the Build and use the Revision for the global $(BuildID).
The $(rev:r) is restarted when the build number changes in any character, so this is the reason why it's restarted whenever the major/minor or the sate changed.
So if you want to use an incremental unique number you can't use the $(rev:r) because then it will be restarted each build.
If you want a number that depends on the major and the minor numbers you need to use the counter expression:
Create 2 variables:
major-minor = 4.16
And a variable that depends on his value and also is a counter:
revision = $[ counter(variables['major-minor'],0) ]
The build number will be:
$(major-minor).$(revision).$(Build.BuildId)
Now, if you will change the major-minor (to 4.17 or 5.16) the revision will be again 0.
I just installed Pharo5.0 and attempting to go through
"Pharo by Example".
When I get to the BouncingAtomsMorph I apply the "Gofer it"
fetch provided by MartinW at Error Unknown variable:BouncingAtomsMorph openInWorld please correct or cancel
This results in a MessageNotUnderstood: FileList class>>registerFileReader:
AnimatedImageMorph class initialize [:cl | cl registerFileReader: self ]
BlockClosure cull:
SystemDicdtionary(Dictionary) at:ifPresent:
AnimatedImageMorph class initialize
MCMethodDefinition postloadOver:
MCPackageLoader basicLoadDefinitions ....
This list can't be copied by swiping with a mouse, so please excuse typos. (Is there any way to get this list in text format?)
Is Pharo5.0 a stable release? I didn't notice any install problems.
My system is CentOS Linux release 7.2.1511
Pharo 5 is a stable release, but the MorphExamplesAndDemos package is no longer updated for the use in Pharo 5.
On the bright side, the error you report is not related to BouncingAtomsMorph but to another example in the package. If the debugger window appears, you can click on Abandon and still use the BouncingAtomMorph by doing:
BouncingAtomsMorph new openInWorld
Probably someone should fix the package, or we should stop mentioning it in Pharo documentation..
Hi I'm using a Confluence macro called 'PockketQuery'(PQ). I have connected to a server located at my client's base through PostgreSQL. I run PQ to fetch results from the db into my confluence page. However, it's fecthing an extra unwanted word "Hallo" along with every result. I m unable to figure out where this string maybe coming from and getting attached to my results like this. Please help me get rid of it.
For example I run a PQ on the db which is supposed to fetch me result "Jack London", so the result that I see is "hallo Jack London".
Note: I use VPN to connect to my client's server and Confluence.
Are you using the latest version from the Marketplace 1.14.6? This issue shouldn't exist in the latest version.
I got an upgrade to version 1.14.6 of Confluence's PocketQuery macro. The issue that I had is resolved, the unwanted string in the result is there no more. The bad part is they don't mention it anywhere on the macro's bug fixes. There are no release notes attached to this fix.Thank you Felix for your help.
I need some help with Stata. I'm not sure if this is the right forum, but hopefully somebody can help me.
The problem occur, when I want to use new commands in stata. I will explain it with an example: command outreg. I assume the problem is the version.
Stata Details:
Version 10.1
Unlimited-user Stata for Windows (network) perpetual license (decompressed in C:\Program Files (x86)\Stata)
I downloaded the command ssc install outreg
I tried the new command with the example given here:
http://www.ats.ucla.edu/stat/stata/faq/outreg.htm
After execution, the following error occur, after outreg using test.doc, nolabel replace
MakeSmat(): 3499 _CColJoin() not found
CalcStats(): - function returned error
<istmt>: - function returned error
Stata.com also provide a solution for the problem:
http://www.stata.com/statalist/archive/2011-07/msg01018.html but a restart of stata doesn't work for my problem.
The necessary library (l_cfrmt described in the stata.com link) is also available:
. mata : mata query
Mata settings
set matastrict off
set matalnum off
set mataoptimize on
set matafavor space may be space or speed
set matacache 400 kilobytes
set matalibs lmatabase;lmataado;lmataopt;l_cfrmt
set matamofirst off
But when I search for the usage of the library l_cfrmt (which is necessary for outreg) there occur the following error-message:
. mata : mata desc using l_cfrmt
c:\ado\plus\l\l_cfrmt.mlib from a more recent version of Stata
It looks, if the version, which I loaded via ssc is not compatible with the Version 10.1 of Stata.
Does somebody have any idea how to solve this problem? I search for a few hours now, but I did't find any possible solution.
Regards,
Michael
First, the code you found on the ucla website for -outreg- is not correct -- John Gallup has since made many changes to the latest version of -outreg-, one of which affects your example. (ignoring your mata issue for a moment) This code should be modified to this in order to make it run:
**install latest outreg
ssc install outreg, replace
use http://www.ats.ucla.edu/stat/stata/notes/hsb1, clear
regress read write
outreg using test.doc, novarlabel replace
the code above works on my machine with an updated version of Stata 12 MP and updated -outreg- version 4.12.
Regarding the mata error: It might be the case that the newest -outreg- just might not work with Stata 10.1 - but I wouldn't give up yet. First, make sure your Stata is fully updated (-update query- and -update all-).
Second, follow the advice of the author of -outreg- in this Statalist thread:
http://www.stata.com/statalist/archive/2011-07/msg01014.html
Finally, if you do have a missing mata component/library, as that thread hints at, and cannot follow this advice to correct it, then consider re-installing Stata and/or contacting Stata tech support.
Apple's doc could have been more clear on how to submit an update version.
As asked in the title,
What's the difference between
version number in itunes connect(which you have to supply when you submit an update)
bundle version in xcode
bundle versions string, short
Are they related in any way?
Yes, they are related. They all refer to the version of your application.
iTunes Connect
This is the version number shown in the App Store; This must be a pure version number like 1.2.3
Bundle Version (CFBundleVersion)
This doesn't need to be a pure version number. This can be something like 12345 or 1.2.3 (Build 12345AB). This is shown in the About window for Mac OS X apps for example and is often more a "Build Number" than a "Version Number".
Bundle Version String (CFBundleShortVersionString)
This value is used as the "real" version number. This must be the same string as used for the version in iTunes Connect.
Update:
As pointed out by #snlehton, the CFBundleVersion has to be a pure version number like 1.2.3 when you want to upload your application to the (iOS) App Store.
Yes they are related but their definition depends on how they are used.
iTunes Connect Version
Always must be a version number, e.g. 1.0
Usage mode 1 - Only CFBundleVersion is set
Bundle Version (CFBundleVersion)
Must be a version number, e.g. 1.0. Must match the iTunes Connect Version.
Usage mode 2 - Both CFBundleVersion and CFBundleShortVersionString
are set
Bundle Version (CFBundleVersion)
Must be a build number, e.g. a single integer like 435163.
Bundle Short Version String (CFBundleShortVersionString)
Must be a version number, e.g. 1.0. Must match the iTunes Connect Version.
Usage mode 2 is the best way to go. Here are some example numbers for an app's upgrade path:
CFBundleShortVersionString CFBundleVersion
1.0 1
1.0.1 2
1.0.2 3
1.2 5 (build 4 was a beta and never released publicly)
1.2.1 6
An extra note on version numbers: If you submit a minor update (e.g. bug fix) to your app you must never miss out periods in the version number, e.g always use 1.0.1 and NEVER 1.01 or you will risk not being able to use certain version numbers in the future because it won't be possible to increment them.
Yep, they all are related.
Version Number in itunesconnect is the version number you need to supply. For example, 2.1.1 or 3.1.2 etc. This also should be equal to the CFBundleShortVersionString.
Bundle Version In Xcode (CFBundleVersion) represents just the Build number which identifies an iteration (released or unreleased) of the application.
Bundle versions string, short (CFBundleShortVersionString) is a number comprising of three integers separated by dots. First one represents any major updates of the application, such as updates that implement new features or major changes. The second integer denotes revisions that implement less prominent features. The third integer represents maintenance releases.
Be careful about CFBundleVersion. It's not only a production build number. This value is checked by Apple during binary upload process, and it can fail it.
Be sure you set CFBundleVersion with the value of CFBundleShortVersionString when you build your release to submission.
See this post about it
The accepted answer is the way to go -- just adding this as an example.
For our last release, the "Bundle Version String, short" was required, and I went ahead and matched it with the Bundle version number (1.2.8 for our app).
I then enabled Testflight, and made the version pending Apple review (1.2.8) available to our internal testers. A tester however found an issue that required fixing, and we deleted the binary in place. When uploading a new build, we got an error indicating the build version was already uploaded.
After reading a few SO links and Apple docs, my understanding was to make the bundle version: 1.2.8.001, while maintaing bundle-version-short the way it was. If a new build is required, we increment bundle-version to 1.2.8.002.
Note: the upload was accepted, and the build shows up as "1.2.8.001" under pre-release. The version number remains 1.2.8.
The accepted answer of this link contains good details ::
Which iOS app version/build number(s) MUST be incremented upon App Store release?
From apple docs
CFBundleVersion ( Bundle version )
CFBundleVersion (String - iOS, OS X) specifies the build version number of the bundle, which identifies an iteration (released or unreleased) of the bundle. The build version number should be a string comprised of three non-negative, period-separated integers with the first integer being greater than zero. The string should only contain numeric (0-9) and period (.) characters. Leading zeros are truncated from each integer and will be ignored (that is, 1.02.3 is equivalent to 1.2.3). This key is not localizable.
CFBundleShortVersionString (Bundle versions string, short)
CFBundleShortVersionString (String - iOS, OS X) specifies the release version number of the bundle, which identifies a released iteration of the app. The release version number is a string comprised of three period-separated integers. The first integer represents major revisions to the app, such as revisions that implement new features or major changes. The second integer denotes revisions that implement less prominent features. The third integer represents maintenance releases.
The value for this key differs from the value for CFBundleVersion, which identifies an iteration (released or unreleased) of the app. This key can be localized by including it in your InfoPlist.strings files.