Return-Path: 
 <issues-return-8011-apmail-cordova-issues-archive=cordova.apache.org@cordova.apache.org>
X-Original-To: apmail-cordova-issues-archive@minotaur.apache.org
Delivered-To: apmail-cordova-issues-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id E519210A78
	for <apmail-cordova-issues-archive@minotaur.apache.org>;
 Fri, 28 Jun 2013 18:42:20 +0000 (UTC)
Received: (qmail 90346 invoked by uid 500); 28 Jun 2013 18:42:20 -0000
Delivered-To: apmail-cordova-issues-archive@cordova.apache.org
Received: (qmail 90305 invoked by uid 500); 28 Jun 2013 18:42:20 -0000
Mailing-List: contact issues-help@cordova.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@cordova.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@cordova.apache.org>
List-Post: <mailto:issues@cordova.apache.org>
List-Id: <issues.cordova.apache.org>
Reply-To: dev@cordova.apache.org
Delivered-To: mailing list issues@cordova.apache.org
Received: (qmail 90296 invoked by uid 99); 28 Jun 2013 18:42:20 -0000
Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Jun 2013 18:42:20 +0000
Date: Fri, 28 Jun 2013 18:42:20 +0000 (UTC)
From: "Shazron Abdullah (JIRA)" <jira@apache.org>
To: issues@cordova.apache.org
Message-ID: <JIRA.12655250.1372380825682.184844.1372444940330@arcas>
In-Reply-To: <JIRA.12655250.1372380825682@arcas>
References: <JIRA.12655250.1372380825682@arcas>
Subject: [jira] [Commented] (CB-4036) <platform> tag should have a "version"
 attribute
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ https://issues.apache.org/jira/browse/CB-4036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13695653#comment-13695653 ] 

Shazron Abdullah commented on CB-4036:
--------------------------------------

That's a better idea - having *min-sdk-version* and *min-os-version*, and iOS has mappings for these as well.

*min-sdk-version* is analogous to the *SDKROOT* Project Build Setting. However, detection is problematic since if a dev choose to use the "Latest iOS SDK" in Xcode, this value is just "iphoneos". If you specified a specific SDK, it would be "iphoneosX.X" where X.X is the iOS version. To properly detect what the "Latest iOS SDK" is, you have to run:
{code}
xcodebuild -showsdks
{code}
.. and parse the iOS SDKS section:
{code}
OS X SDKs:
	Mac OS X 10.7                 	-sdk macosx10.7
	OS X 10.8                     	-sdk macosx10.8

iOS SDKs:
	iOS 6.1                       	-sdk iphoneos6.1

iOS Simulator SDKs:
	Simulator - iOS 5.1           	-sdk iphonesimulator5.1
	Simulator - iOS 6.1           	-sdk iphonesimulator6.1
{code}

*min-os-version* is pretty straightforward, it is just the *IPHONEOS_DEPLOYMENT_TARGET* Build Setting, and this is just a number (X.X). Note that you have to read the value from the *Target*, not *Project* Build Setting, since anything in the *Target* overrides the *Project* Build Setting.
                
> <platform> tag should have a "version" attribute 
> -------------------------------------------------
>
>                 Key: CB-4036
>                 URL: https://issues.apache.org/jira/browse/CB-4036
>             Project: Apache Cordova
>          Issue Type: Improvement
>            Reporter: Shazron Abdullah
>
> This might be hole that we didn't consider.
> I know implicitly if the plugin supported an "engine" version we support what the engine supports, but here could be one scenario.
> For example, with iOS 7, a plugin CDVFooBar use this awesome NSWhizBang framework. Fine, with iOS 7, you have to of course build with the iOS 7 SDK, and you can support iOS 6 with a Deploy Target build setting.
> It runs on iOS 7 - yay.
> It.. blows up on iOS 6 at runtime, because of course NSWhizBang framework does not exist on iOS 6.
> Now you say, why don't you do Obj-C runtime checks and weak link the framework? Yes, the plugin author can do that but a plugin user, by parsing the plugin xml (using a tool, or optically, whatever) cannot know that the plugin does NOT work on iOS 6 - and even though it "runs" on iOS 6, it does nothing, which is useless and wastes a lot of time.
> So - my proposal is, to add a *"version"* attribute on the *<platform>* tag. It should follow the syntax for the <engine> version attribute. 
> What would be the default if the version attribute is not there? Not sure what a reasonable default is yet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira