You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by "Gary Bentley (Created) (JIRA)" <ji...@apache.org> on 2012/01/31 06:01:11 UTC
[jira] [Created] (CB-209) Improve ios upgrade procedure to take
burden off of end developer
Improve ios upgrade procedure to take burden off of end developer
-----------------------------------------------------------------
Key: CB-209
URL: https://issues.apache.org/jira/browse/CB-209
Project: Apache Callback
Issue Type: Improvement
Components: iOS
Affects Versions: 1.3.0
Environment: IOS
Reporter: Gary Bentley
Assignee: Shazron Abdullah
Priority: Critical
Currently to upgrade phone gap to a new version it is recommended that you create a completely new phone gap project and then migrate your settings across to the new project.
This is problematic for a number of reasons:
1. There are many settings that have to be transfered, including splash images and icons, external hosts, code signing setup, orientations and more. It is onerous to have to manually set these up every time you want to use a new version of phone gap.
2. It breaks your source control since the new project is not under source control, it also breaks your archives within XCode.
Compare this with upgrading to a new phone gap version for Android where all you need to do is change the .jar and .js file.
Having to manually re-create your project for a new version in ios is a significant barrier and can be a huge time sync.
What is needed is an upgrade mechanism that is similar to Android, the end developer should not be re-creating a project for new versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-209) Improve ios upgrade procedure to take
burden off of end developer
Posted by "Shazron Abdullah (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CB-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196719#comment-13196719 ]
Shazron Abdullah commented on CB-209:
-------------------------------------
The upgrade procedure has been improved for 1.4: https://github.com/apache/incubator-cordova-ios/blob/master/PhoneGap%20Upgrade%20Guide.md
Your existing project will work, but the classes it depends on have been deprecated and may be removed in a future version.
Sorry - things will break sometimes but we try to minimize it, and hopefully an upgrade guide helps.
For upgrades, in 1.4 the significant change is to AppDelegate.* only.
Feedback on the guide welcome!
related: https://issues.apache.org/jira/browse/CB-168
> Improve ios upgrade procedure to take burden off of end developer
> -----------------------------------------------------------------
>
> Key: CB-209
> URL: https://issues.apache.org/jira/browse/CB-209
> Project: Apache Callback
> Issue Type: Improvement
> Components: iOS
> Affects Versions: 1.3.0
> Environment: IOS
> Reporter: Gary Bentley
> Assignee: Shazron Abdullah
> Priority: Critical
>
> Currently to upgrade phone gap to a new version it is recommended that you create a completely new phone gap project and then migrate your settings across to the new project.
> This is problematic for a number of reasons:
> 1. There are many settings that have to be transfered, including splash images and icons, external hosts, code signing setup, orientations and more. It is onerous to have to manually set these up every time you want to use a new version of phone gap.
> 2. It breaks your source control since the new project is not under source control, it also breaks your archives within XCode.
> Compare this with upgrading to a new phone gap version for Android where all you need to do is change the .jar and .js file.
> Having to manually re-create your project for a new version in ios is a significant barrier and can be a huge time sync.
> What is needed is an upgrade mechanism that is similar to Android, the end developer should not be re-creating a project for new versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-209) Improve ios upgrade procedure to take
burden off of end developer
Posted by "Shazron Abdullah (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CB-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shazron Abdullah resolved CB-209.
---------------------------------
Resolution: Fixed
Fix Version/s: 1.4.0
Upgrade Guide solves this.
> Improve ios upgrade procedure to take burden off of end developer
> -----------------------------------------------------------------
>
> Key: CB-209
> URL: https://issues.apache.org/jira/browse/CB-209
> Project: Apache Callback
> Issue Type: Improvement
> Components: iOS
> Affects Versions: 1.3.0
> Environment: IOS
> Reporter: Gary Bentley
> Assignee: Shazron Abdullah
> Priority: Critical
> Fix For: 1.4.0
>
>
> Currently to upgrade phone gap to a new version it is recommended that you create a completely new phone gap project and then migrate your settings across to the new project.
> This is problematic for a number of reasons:
> 1. There are many settings that have to be transfered, including splash images and icons, external hosts, code signing setup, orientations and more. It is onerous to have to manually set these up every time you want to use a new version of phone gap.
> 2. It breaks your source control since the new project is not under source control, it also breaks your archives within XCode.
> Compare this with upgrading to a new phone gap version for Android where all you need to do is change the .jar and .js file.
> Having to manually re-create your project for a new version in ios is a significant barrier and can be a huge time sync.
> What is needed is an upgrade mechanism that is similar to Android, the end developer should not be re-creating a project for new versions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira