I have an Android app with versionName=1.0.5 and versionNumber=7 in Android Manifest.xml file. Whenever I repackage my app the vesionName automatically changes to 1.0.7.0. I have no idea why it does this. I want my application versionName to be same as in the Android Manifest.xml file.
Further to your comment, the convention on BlackBerry platforms is (as you say) to use a dotted quad as the version name. For the sake of discussion lets call the four numbers:
Major
Minor
Release
Build
The Major number indicates very significant changes that will often preclude working on older hardware. BBOS 4, 5, 6, 7, 10 are examples of this. A device released to run OS N will usually not be able to run OS N+1.
The Minor numbers indicate significant changes. These are often additional APIs or capabilities but don't usually indicate hardware incompatibilities. For example versions 10.0, 10.1, 10.2 and 10.3.
The Release number indicates changes which are fixes or minor enhancements but don't normally come with major new features or APIs.
The Build number is a one-up number incremented each time the product with a particular Major.Minor.Release is built. It is normal for these numbers to reach the hundreds or thousands before a product is released.
Clearly given a versionNumber to put in the version string with versionName it doesn't make sense to put it in the build field. The Release field makes the most sense.
Related
Let’s imagine I have an iOS app. In version 2.0, I added a bunch of new features, but to implement them, I had to drop support for an older iOS version which is still in heavy use (remember, it’s a hypothetical scenario).
Later, I discovered a super critical bug in version 1.0 of my app that needs to be patched.
What are my options in terms of distribution?
It seems that it’s not possible to release version 1.0.1 if version 2.0 is already on the App Store. Adding back support for the older iOS version and fixing the bug in 2.0.1 is not feasible because that would require removal of the new features.
The problem here is that I can’t think of a way you could submit a version that updates version 1 without letting your version 2 users download it. So if you want to update version 1 you will just have to bite the bullet and meld your versions together. Use availability so that the new features are not present for your version 1 users.
Over the past few years, I have been developing/maintaining a Lite and Pro version of an app. I do this by developing new features for the Pro version, and then duplicating this project, renaming all of the attributes in the Pro version to reflect the Lite version's attributes (app name, bundle identifier, etc.). Although they do share a lot of the same code (I'd say about 90% of the app); however, they do have minor differences: for eg. the Lite version is light, whereas the Pro version has more of a darker, 'professional' look to it. Another example would be something like the Lite version having an "Upgrade" button, whereas the Pro version will have multiple buttons that actually have functions.
TL;DR: I have two versions of an app, a Lite and a Pro version. They share 90% of the same code, but have minor differences (like theme colours and different buttons with different functions).
What is the best way to go about maintaining a Lite and a Pro version of an app to optimize for maximum efficiency? (Specifically in Xcode, if you feel like getting into detail). I do use GitHub as well, so possibly a method using branches?
I know Apple and iTunesConnect are very strict about version numbers always incrementing (which has certainly caused problems for us in the past), so I am naturally hesitant at introducing a four-segment version for a one-off app update with the intent of going back to three segments for the next release.
For example, the current version is 1.0.7. We need to push an update out for an app that is not on the normal release cadence (minor update, just some graphics changed). Rather than have to bump all future versions, I was thinking to release this patch as 1.0.7.1, such that the next version can resume at 1.0.8.
However my worry is that if I introduce a four-segmented version of 1.0.7.1, Apple won't let me go back to three segments for 1.0.8.
I obviously can't just try it out to see given that Apple won't let you delete versions.
No problem about that. If version number increments, then there won't be any problem.
Let's just base this on real data :) ...
Notice the change from version 7.0.3 to 7.1.
I get the "BASE SDK Missing" when re-opeing projects. (I got the latest build of xcode, and latest SDK installed.)
It seems to be happening when I quit a project, (not exiting xcode), and re-open the project after a while. I have tried both, with and without my iPhone plugged in. I have tried to fix the problem like described here, but it does not help for me. - It just makes it even worse! (unrecognizable SDK)
The only way I have managed to get it back to normal, is to do a manual re-boot of my mac, plugged in my phone, waited until it has checked my iPhone, and then, opened xcode. Time consuming and annoying!
Why does it happen and what is the trick to fix this?
Your recent upgrade of Xcode likely removed the earlier SDK that your project was set to use. There are a couple of solutions for the problem. The most simple solution is to always select the "Latest" SDK in your project's settings and not select a specific option. You may be uncomfortable with the idea and want to run your app on an older device but it's important you understand that all of the newer SDKs can generate code that works on older versions of iOS. There's a separate hard to remember option for setting the deploy target. (It took me a while to learn how/why to use this but it's well worth it.)
The second option is to actually find a version of the SDK that your project is set to and attempt to reinstall it. I suggest going this route only if necessary as it's not guaranteed to work in each case. Older SDKs may or may not work in later versions of Xcode (Eg. SDK 3.0 might not work in Xcode 4.3.2) due to major changes in the toolchains. Tools like gcc/gdb are deprecated in favor of llvm/lldb. Still, you may have a valid reason for using an older SDK. You may have to fix a bug that is present only when using the older toolchain or you may need to reproduce a problem that only happens with builds generated from your build server. In many of these cases it might be easier to upgrade where the problem occurs (Eg. upgrade the tools on the build server) or downgrade your dev environment. (Install an older version of Xcode.)
The reasoning behind the frustration is that Apple highly encourages rapid adoption of it's latest tools and technologies. It creates a better product as the dev community is forced to stay current and competitive while the users are forced to maintain upgrades to ensure apps continue to work. This is in contrast with the traditional model of backward compatibility allowing developers to support revision -n of a product/platform. It is also great for business since rapid adoption of the latest often encourages purchase of newer hardware and products to get the best experience. The rapid adoption ensures the more robust software along with bug fixes, enhancements make it to the majority of consumers overall increasing their penetration in the market.
You have to set your target and project's base SDK to "Latest" and not an explicit option. If you choose one explicitly it seems to break if you update xcode versions.
If I develop Blackberry application for OS version 6.0, will the application be compatible with OS version 4.5? If not, is there some way to port the application easily?
If you develop against a specific SDK (eg 6.0) your application will only be deployable to devices that use the matching OS version (6.0 in this case).
In order to develop applications that specifically target different OS versions, you must build separate deployable binaries for each version. Alternatively, you can build for the lowest common denominator -- if you want to support OS 4.5, build for 4.5 and your app will run (though not always gracefully) on all later BB OS versions.
Two open source projects that you can use for examples are BBSSH and LogicMail.
Neither of these uses preprocessor directives, however both take slightly different approaches to managing multiple target OS's; which solution is more appropriate is best determined by your own needs. Both use ant-based builds; and I think both target from OS 4.5 to 6.0. (Older versions of LogicMail target back to 4.1 I believe)
Build scripts can be found here:
BBSSH SVN (build.xml,build-impl.xml, build.properties)
LogicMail SVN (build.xml, build.properties)
Both projects can also be looked to for specific methods of handling things like utilizing features introduced in later OS versions seamlessly to your users -- either providing a custom implementation prior for earlier versions, or disabling the functionality as is appropriate.
Finally a quick note: if you continue to not accept valid answers, you'll soon find that people are less willing to answer you.
Try to use "Preprocessor Directives" to support multiple blackberry devices.
I m not 100% sure but probably not, because version 6.0 uses newer libraries.But try develope in lower version os and it will run at higher version.
hope it helps
Wblade
For an example of a quality open source project that supports many different BB OS versions, check out LogicMail.
The ant build.xml loads platform-specific classes based on the target:
<if><isset property="jde460.home"/><then>
<fileset id="bb460_fileset" dir="..">
<include .../>
...
As far as I can tell, this project does not rely on the preprocessor.