You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Shazron <sh...@gmail.com> on 2016/03/08 20:55:05 UTC
[PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
See:
https://issues.apache.org/jira/browse/CB-10775
Problem:
For cordova-ios, "cordova platform update" does its own thing, which
causes problems.
Proposal:
Change "cordova platform update ios@version" to be basically an alias for:
"cordova platform rm ios"
"cordova platform add ios@version"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Steven Gill <st...@gmail.com>.
For Android, Joe brought up some real concerns. People not using build.json
for releasing end up updating files within the android platform itself.
Changes people might make to gradle files would get wiped out. People who
copy 9patch files into their android projects.
Some of these can be handled by telling people to use after_install hooks
to move files over or making some of these changes first class in cordova.
Might be best to leave Android the way it is for now. +1 to moving forward
with iOS making this change. Other platforms that feel comfortable treating
platforms as artifacts (the dream!) and want to make this change, post it
here!
On Tue, Mar 8, 2016 at 2:36 PM, So, Byoungro <by...@intel.com> wrote:
> I second that. +1
>
> Byoungro So
> SSG / DPD / Mobile Computing and Compilers
> Intel Corporation
>
> From: Anis KADRI <an...@gmail.com>>
> Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> dev@cordova.apache.org<ma...@cordova.apache.org>>
> Date: Tuesday, March 8, 2016 at 2:34 PM
> To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> dev@cordova.apache.org<ma...@cordova.apache.org>>
> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
> cordova-ios
>
> I support this as well. Real updates never work. Better to remove/add.
>
> On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <stevengill97@gmail.com
> <ma...@gmail.com>> wrote:
>
> I would also like to see this happen. Would this cause problems if we did
> this for other platforms?
>
> On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com<mailto:
> shazron@gmail.com>> wrote:
>
> > See:
> > https://issues.apache.org/jira/browse/CB-10775
> >
> > Problem:
> > For cordova-ios, "cordova platform update" does its own thing, which
> > causes problems.
> >
> > Proposal:
> > Change "cordova platform update ios@version" to be basically an alias
> for:
> > "cordova platform rm ios"
> > "cordova platform add ios@version"
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<mailto:
> dev-unsubscribe@cordova.apache.org>
> > For additional commands, e-mail: dev-help@cordova.apache.org<mailto:
> dev-help@cordova.apache.org>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
cordova-ios
Posted by Parashuram N <pa...@microsoft.com>.
+1 to Jesse’s new proposal. Looks like a nice idea and we don’t break existing tooling. We could symlink /platforms/ios to always point to latest, but that would not work on Windows. This is a better approach.
On 3/14/16, 1:29 PM, "Jesse" <pu...@gmail.com> wrote:
>Considering all of the points previously mentioned, I would like to make a
>supplementary proposal.
>
>We seem to all agree that platform rm+add is ideal in a world where we can
>truly consider platforms as artifacts, but we are really not there yet.
>The zipped snapshot of the platform before the update that Carlos mentions
>is a good non-destructive way of allowing a developer the chance to always
>go back.
>I would like to take this approach one step further and suggest:
>(note: I am using 'ios' as the example platform, but this applies to
>any/all platforms )
>
>1. when updating a project, we rename the previous platforms/ios/ to
>include the version it was, and leave it in the platforms folder.
>ex. platforms/ios/ -> platforms/ios@4.0.1/
>
>2. platforms/ios would always contain the latest ios version installed for
>this project. This would allow most tooling to work unchanged, and
>sidesteps symlink issues on windows with things like ios-latest -> ios@4.02
>
>3. [optional or stretch goal] 'platform rm ios' could be used to go back to
>the previous 'current' version ( according to semver ) or should this be a
>new command? like 'cordova platform pop ios' ?
>
>4. we can add a flag to platform update ios --kill to do a destructive
>update for users who know that that is what they want.
>
>5. [optional | stretch ] allow build/run of platform artifacts as well, so
>developers can run commands like : 'cordova run ios@4.0.1'
>
>6. the platform listed in config.xml would always be the latest one,
>regardless of how many artifacts were still around.
>
>Thoughts? Issues? Comments?
>
>
>
>
>
>
>
>
>
>
>@purplecabbage
>https://na01.safelinks.protection.outlook.com/?url=risingj.com&data=01%7c01%7cpanarasi%40microsoft.com%7ce5118e6f28684a85e33a08d34c476c39%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=q8G%2fXrFtV4GigDIKa7s5cH8bZlfgrIwwjcxZtu3R1Xs%3d
>
>On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <da...@cellartracker.com> wrote:
>
>> As a user of cordova (and list lurker), I thought I'd chime in and say
>> Carlos hit on some very good points. In theory I like the idea of treating
>> platforms like build artifacts, but in reality -- at least for my current
>> usage -- things are far from that. Making this type of change will make my
>> upgrades more challenging. I'm willing to live with that, but PLEASE make
>> sure you do a backup (or tell the user to) "just in case" before nuking
>> their directory.
>>
>> Right now, I find I do more native (non CLI) development on iOS compared
>> to other platforms. I'd have to do a full inventory of all of my native
>> customizations, but as Carlos mentions it is a combination of:
>>
>> - working around bugs/limitations in the tools
>> - additional AppDelegate customizations for native analytics libraries and
>> error handling as our app is remotely hosted
>> - the addition of dependencies as cocoapods
>> - other build/plist customizations which are far simpler to modify
>> directly, e.g. adding an entitlements file to support universal links, or
>> adding ITSEncryptionExportComplianceCode to the plist to simplify app
>> submissions
>>
>> Anyway, please just keep in mind those of us who may be doing things the
>> "old way" as you move forward here.
>>
>> Dan
>>
>> -----Original Message-----
>> From: Carlos Santana [mailto:csantana23@gmail.com]
>> Sent: Tuesday, March 08, 2016 3:16 PM
>> To: dev@cordova.apache.org
>> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
>> cordova-ios
>>
>> I was never a fan of the "platform update" command since it was not fully
>> tested across the board.
>> like all the permutations possible to/from upgrade. meaning going for very
>> old like 3.6 to 5.1
>>
>> If we do this I think it will break a lot of people that got used to
>> changing files inside platform/ios/ in terms of changing XCode settings in
>> pbxproj like:
>> - use story board to launch app to be able to support ipad pro
>> - some initialization code in AppDelegate
>> - Any native code they added like NativeUI to mix web and native
>> - Changes to StoryBoard to adjust webview inside native view
>> - Build and Signing settings in project or target in XCode
>> - Installation of cocoapods
>> - Xcode Build phases scripts
>>
>> Meaning that they will need to restore or generate all this things with
>> hooks or plugins.
>>
>> I know that Darryl Pogue and Tommy have projects where they can
>> successfully treat platfforms folder as 100% build artifact that they can
>> throw away. But to get there is not super easy
>>
>> "platform update ios" has being scoped to only touch the CordovaLib xcode
>> project, leaving the app xcode project not touched that's why it's being
>> safe all along
>>
>> What was the root cause of the recent problems with 4.1.0 for update?
>>
>> Maybe we can restrict update command to major version, meaning going from
>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
>>
>> In the current release of the IBM MobileFirst, were we have a CLI to wrap
>> cordova commands we had a "$ mfp cordova platform update"
>> We took a backup of the platform folder and create a zip with a timestamp
>> (like ios_1457477724404.zip)
>> We did this just in case the command was destructive and user didn't lost
>> files just in case they didn't have all files checked-in/backup
>>
>> So doing a backup would be good if we move forward with this destructive
>> action of doing a platform remove
>>
>>
>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <by...@intel.com> wrote:
>>
>> > I second that. +1
>> >
>> > Byoungro So
>> > SSG / DPD / Mobile Computing and Compilers
>> > Intel Corporation
>> >
>> > From: Anis KADRI <an...@gmail.com>>
>> > Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>> > Date: Tuesday, March 8, 2016 at 2:34 PM
>> > To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
>> > cordova-ios
>> >
>> > I support this as well. Real updates never work. Better to remove/add.
>> >
>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <stevengill97@gmail.com
>> > <ma...@gmail.com>> wrote:
>> >
>> > I would also like to see this happen. Would this cause problems if we did
>> > this for other platforms?
>> >
>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com<mailto:
>> > shazron@gmail.com>> wrote:
>> >
>> > > See:
>> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7ce5118e6f28684a85e33a08d34c476c39%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pl3ikV3R7hGuGK5DrODaYDciW%2b47dE%2bUIxNUZyAUh4I%3d
>> > >
>> > > Problem:
>> > > For cordova-ios, "cordova platform update" does its own thing, which
>> > > causes problems.
>> > >
>> > > Proposal:
>> > > Change "cordova platform update ios@version" to be basically an alias
>> > for:
>> > > "cordova platform rm ios"
>> > > "cordova platform add ios@version"
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<mailto:
>> > dev-unsubscribe@cordova.apache.org>
>> > > For additional commands, e-mail: dev-help@cordova.apache.org<mailto:
>> > dev-help@cordova.apache.org>
>> > >
>> > >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Shazron <sh...@gmail.com>.
In the interim, I filed: https://issues.apache.org/jira/browse/CB-12948 and
will send a PR for comment
On Fri, Dec 2, 2016 at 4:56 PM, Shazron <sh...@gmail.com> wrote:
> This has not been resolved yet. We'll discuss more next week.
>
> Archive link to this thread just in case you don't have it:
> https://lists.apache.org/thread.html/dfeaab003cf67e915e342ebbf38268
> 88c3b604d151e01dbaf9ab9950@1457466905@%3Cdev.cordova.apache.org%3E
>
> Jesse's proposal to help fix this:
> https://github.com/cordova/cordova-discuss/issues/50
>
>
> On Sun, Mar 20, 2016 at 12:06 PM, julio cesar sanchez <
> jcesarmobile@gmail.com> wrote:
>
>> Not sure how many people still uses the non CLI approach, but the
>> phonegap.com tutorial for android embedded webviews it uses it.
>>
>> 2016-03-19 2:34 GMT+01:00 Shazron <sh...@gmail.com>:
>>
>> > Another issue: we still document the non-CLI way to update projects.
>> > This was brought to my attention in a comment [1] in CB-10775.
>> >
>> > The platform specific way is still mentioned [2], and update
>> > instructions for iOS [3] and android [4] still exist.
>> >
>> > I think we should not have any more "update" docs that don't involve
>> > the CLI. What do you think?
>> >
>> > [1]
>> > https://issues.apache.org/jira/browse/CB-10775?focusedCommen
>> tId=15200735&page=com.atlassian.jira.plugin.system.
>> issuetabpanels:comment-tabpanel#comment-15200735
>> > [2]
>> > https://cordova.apache.org/docs/en/latest/guide/overview/ind
>> ex.html#development-paths
>> > [3]
>> > http://cordova.apache.org/docs/en/latest/guide/platforms/
>> ios/upgrade.html
>> > [4]
>> > http://cordova.apache.org/docs/en/latest/guide/platforms/
>> android/upgrade.html
>> >
>> >
>> > On Wed, Mar 16, 2016 at 7:44 AM, Carlos Santana <cs...@gmail.com>
>> > wrote:
>> > > yep I agree Julio about adding more power to config.xml, that's
>> > basically
>> > > what Mike's hook those allow <config-file> tag in config.xml
>> > >
>> > >
>> > > On Wed, Mar 16, 2016 at 10:23 AM julio cesar sanchez <
>> > jcesarmobile@gmail.com>
>> > > wrote:
>> > >
>> > >> I like Jesse's proposal
>> > >>
>> > >> for #3 I think we should use a new command, I like cordova
>> *downgrade*
>> > >> platform
>> > >>
>> > >> As I usually read most cordova questions on stackoverflow, most
>> people
>> > is
>> > >> editing and tellign others to edit the .plist manually and doing some
>> > other
>> > >> manual changes. I always point them to use hooks or plugins to do
>> that,
>> > but
>> > >> as it's harder they don't want to do it.
>> > >>
>> > >> BTW, I think we should add a way to write on the AndroidManifest.xml
>> and
>> > >> info.plist from the config.xml as phonegap build does, using the
>> > >> config-file tag. Right now it's possible to use the config-file tag
>> on
>> > >> plugin.xml but not on config.xml
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> 2016-03-16 14:54 GMT+01:00 Carlos Santana <cs...@gmail.com>:
>> > >>
>> > >> > Here is an example [1] of hooks created by ionic team member
>> extending
>> > >> > config.xml to allow user to configure their native sdk settings
>> > allowing
>> > >> > have platforms as build artifacts.
>> > >> >
>> > >> > This could be a start at looking at some basic configuration
>> settings
>> > via
>> > >> > hooks cordova provides or just in cordova tooling (i.e. platformAPI
>> > >> parser)
>> > >> >
>> > >> > [1]: https://github.com/mhartington/cordova-config-utils
>> > >> >
>> > >> >
>> > >> > On Tue, Mar 15, 2016 at 10:31 PM Carlos Santana <
>> csantana23@gmail.com
>> > >
>> > >> > wrote:
>> > >> >
>> > >> > > Scratch the "migrate cli command" idea. Now I think about it
>> really
>> > >> messy
>> > >> > > and it will be another hackHooks.
>> > >> > >
>> > >> > > I think we concentrate to provide more capabilities thru
>> config.xml
>> > and
>> > >> > > hooks for making migration more smooth.
>> > >> > >
>> > >> > > Like a running hooks on after_platform_update event and providing
>> > more
>> > >> > > information in the hook context argument with from to platform
>> info
>> > >> > >
>> > >> > >
>> > >> > >
>> > >> > > On Tue, Mar 15, 2016 at 9:52 PM Carlos Santana <
>> > csantana23@gmail.com>
>> > >> > > wrote:
>> > >> > >
>> > >> > >> By "I like the proposal and deleting all previous versions I
>> don't
>> > see
>> > >> > as
>> > >> > >> an issue." I meant that I don't have an issue if we don't have
>> this
>> > >> > feature
>> > >> > >> to clean old. I prefer not to have it
>> > >> > >>
>> > >> > >> On Tue, Mar 15, 2016 at 9:51 PM Carlos Santana <
>> > csantana23@gmail.com>
>> > >> > >> wrote:
>> > >> > >>
>> > >> > >>> I like the proposal and deleting all previous versions I don't
>> > see as
>> > >> > an
>> > >> > >>> issue.
>> > >> > >>>
>> > >> > >>> I didn't get the part of using symlinks, I don't symlinks they
>> > bring
>> > >> a
>> > >> > >>> lot of problems to implement correctly I prefer we stick to
>> real
>> > >> > directory
>> > >> > >>> and rename directories, user can choose to create symlinks on
>> > their
>> > >> > needs,
>> > >> > >>> we would just handle them.
>> > >> > >>>
>> > >> > >>> If end up doing a flag I prefer just deleting the one being
>> > replace,
>> > >> as
>> > >> > >>> --no-backup
>> > >> > >>> cordova platform update ios --no-backup (using nopt notation)
>> > >> > >>> will do the rename ios -> ios@4.0.1
>> > >> > >>> will do the add ios
>> > >> > >>> then only then if the add works and all plugins present get
>> > install
>> > >> and
>> > >> > >>> cli exist with none zero go and don't save the backup and
>> delete
>> > the
>> > >> > folder
>> > >> > >>> that was rename to ios@4.0.1
>> > >> > >>>
>> > >> > >>> But I agree for now implement default to always do a backup, no
>> > flag
>> > >> > >>> (maybe experimental)
>> > >> > >>>
>> > >> > >>> User needs to be explicit on harmful actions, they can do
>> > platform rm
>> > >> > >>> ios@4.0.1 will simple delete /platforms/ios@4.0.1
>> > >> > >>> and he can do it for any platform current/active or old backups
>> > >> > >>>
>> > >> > >>> I'm OK about this proposal and we can start a new one that
>> covers
>> > how
>> > >> > to
>> > >> > >>> help with migration. Since update becomes backup,
>> > >> > >>> We need to think how much we invest in migration, value of
>> > cordova is
>> > >> > on
>> > >> > >>> the runtime (core platform, and plugins)
>> > >> > >>>
>> > >> > >>> We can do start iterating with implementing enablement but
>> > specific
>> > >> > >>> migration tasks/actions are built on real experiences by the
>> > >> community.
>> > >> > >>> Meaning plugins/extensions that are plugable to handle
>> migration,
>> > >> today
>> > >> > >>> peope do with hooks, I call those hackHooks :-), hooks that do
>> > hacks
>> > >> to
>> > >> > >>> make platforms build artifacts and be able to restore
>> everything
>> > that
>> > >> > can't
>> > >> > >>> be restore with platform+plugins+config.xml
>> > >> > >>>
>> > >> > >>> So the flow I see if as the following:
>> > >> > >>>
>> > >> > >>> cordova platform update ios
>> > >> > >>> ....
>> > >> > >>> mv platforms/ios platforms/ios@4.0.1
>> > >> > >>> add platforms/ios
>> > >> > >>> ....
>> > >> > >>> cordova migrate ios ios@4.0.1
>> > >> > >>>
>> > >> > >>> This cli migrate command migrate helps user migrate things from
>> > 4.0.1
>> > >> > >>> (ios@4.0.1) to 4.1 (ios/current)
>> > >> > >>> migrate will run the actions/tasks/extensions added by the
>> user,
>> > this
>> > >> > >>> actions/tasks/extensions (don't have a good name for migrations
>> > >> > "things")
>> > >> > >>> will be available on npm with keyword cordova:migrate
>> > >> > >>> For example there can be a command "migrate add
>> > >> > >>> cordova-migrate-entitlements" (this tasks migrate ios
>> entitlements
>> > >> > from an
>> > >> > >>> old project to a new project)
>> > >> > >>> this tasks/extension will be added to list of steps to do to
>> > automate
>> > >> > >>> migration when cli command migrate runs
>> > >> > >>> Cordova project can provide the tooling and maybe a handful (or
>> > zero)
>> > >> > of
>> > >> > >>> well known tasks for migration, but not more, the rest will
>> come
>> > from
>> > >> > the
>> > >> > >>> community/3rd party to maintain and publish, this will be a way
>> > for
>> > >> > people
>> > >> > >>> like Darryl and Tommy that have knowledge on migration and
>> hooks
>> > they
>> > >> > can
>> > >> > >>> convert those to migration npm packages to share.
>> > >> > >>>
>> > >> > >>>
>> > >> > >>>
>> > >> > >>>
>> > >> > >>>
>> > >> > >>>
>> > >> > >>> On Mon, Mar 14, 2016 at 8:21 PM Jesse <purplecabbage@gmail.com
>> >
>> > >> wrote:
>> > >> > >>>
>> > >> > >>>> Yeah, the simple approach is probably the best!
>> > >> > >>>>
>> > >> > >>>> Move to strike --kill or any variation of it, and let
>> developers
>> > >> > delete
>> > >> > >>>> what they want to. If it proves to be an issue, then we will
>> > >> address
>> > >> > >>>> it.
>> > >> > >>>>
>> > >> > >>>>
>> > >> > >>>> @purplecabbage
>> > >> > >>>> risingj.com
>> > >> > >>>>
>> > >> > >>>> On Mon, Mar 14, 2016 at 3:58 PM, Parashuram N <
>> > >> panarasi@microsoft.com
>> > >> > >
>> > >> > >>>> wrote:
>> > >> > >>>>
>> > >> > >>>> > Instead of adding an entire flag to remove previous
>> versions,
>> > does
>> > >> > it
>> > >> > >>>> make
>> > >> > >>>> > sense to have cordova platform android@oldVersion.
>> > Alternatively,
>> > >> > >>>> users
>> > >> > >>>> > could simple use the terminal to delete older versions from
>> the
>> > >> > >>>> command
>> > >> > >>>> > line inside the platform folders.
>> > >> > >>>> > If we have users asking for a way to “remove all older
>> > platforms”,
>> > >> > we
>> > >> > >>>> > could then introduce this flag.
>> > >> > >>>> >
>> > >> > >>>> > On 3/14/16, 2:07 PM, "Shazron" <sh...@gmail.com> wrote:
>> > >> > >>>> >
>> > >> > >>>> > >Note:
>> > >> > >>>> > >I prefer `--remove-previous-versions` to `--kill` so as to
>> be
>> > >> > >>>> > >unambiguous and explicit.
>> > >> > >>>> > >
>> > >> > >>>> > >On Mon, Mar 14, 2016 at 2:01 PM, Shazron <
>> shazron@gmail.com>
>> > >> > wrote:
>> > >> > >>>> > >> +1 I like it (esp reasons in #2)
>> > >> > >>>> > >>
>> > >> > >>>> > >> I agree that platform rm+add is not there yet, case in
>> point
>> > >> all
>> > >> > >>>> the
>> > >> > >>>> > >> related issues in the "Issue Links" in this issue:
>> > >> > >>>> > >>
>> > >> > >>>> >
>> > >> > >>>>
>> > >> >
>> > >>
>> > https://na01.safelinks.protection.outlook.com/?url=https%3a%
>> 2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%
>> 7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d3
>> 4c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoB
>> ecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
>> > >> > >>>> > >>
>> > >> > >>>> > >> Some comments:
>> > >> > >>>> > >>
>> > >> > >>>> > >> `cordova platform ls` should list these previous
>> versions as
>> > >> > well.
>> > >> > >>>> > >>
>> > >> > >>>> > >> `cordova platform add ios` should not delete these
>> previous
>> > >> > >>>> versions?
>> > >> > >>>> > >>
>> > >> > >>>> > >> `cordova platform update ios --kill` kills *all* previous
>> > >> > versions,
>> > >> > >>>> > >> regardless of major version (clarification)
>> > >> > >>>> > >>
>> > >> > >>>> > >> `cordova platform rm ios` should just remove the current
>> > >> version
>> > >> > >>>> so it
>> > >> > >>>> > >> doesn't get confusing. If we have listing of the previous
>> > >> > versions
>> > >> > >>>> > >> above in `cordova platform ls`, you would have to
>> explicitly
>> > >> do a
>> > >> > >>>> > >> `cordova platform rm ios@4.0.1` for example. However,
>> this
>> > >> does
>> > >> > >>>> not
>> > >> > >>>> > >> solve for a way to remove *all* previous versions (we
>> will
>> > have
>> > >> > to
>> > >> > >>>> > >> figure out a new command?)
>> > >> > >>>> > >>
>> > >> > >>>> > >>
>> > >> > >>>> > >> On Mon, Mar 14, 2016 at 1:29 PM, Jesse <
>> > >> purplecabbage@gmail.com>
>> > >> > >>>> wrote:
>> > >> > >>>> > >>> Considering all of the points previously mentioned, I
>> would
>> > >> like
>> > >> > >>>> to
>> > >> > >>>> > make a
>> > >> > >>>> > >>> supplementary proposal.
>> > >> > >>>> > >>>
>> > >> > >>>> > >>> We seem to all agree that platform rm+add is ideal in a
>> > world
>> > >> > >>>> where we
>> > >> > >>>> > can
>> > >> > >>>> > >>> truly consider platforms as artifacts, but we are really
>> > not
>> > >> > >>>> there yet.
>> > >> > >>>> > >>> The zipped snapshot of the platform before the update
>> that
>> > >> > Carlos
>> > >> > >>>> > mentions
>> > >> > >>>> > >>> is a good non-destructive way of allowing a developer
>> the
>> > >> chance
>> > >> > >>>> to
>> > >> > >>>> > always
>> > >> > >>>> > >>> go back.
>> > >> > >>>> > >>> I would like to take this approach one step further and
>> > >> suggest:
>> > >> > >>>> > >>> (note: I am using 'ios' as the example platform, but
>> this
>> > >> > >>>> applies to
>> > >> > >>>> > >>> any/all platforms )
>> > >> > >>>> > >>>
>> > >> > >>>> > >>> 1. when updating a project, we rename the previous
>> > >> > platforms/ios/
>> > >> > >>>> to
>> > >> > >>>> > >>> include the version it was, and leave it in the
>> platforms
>> > >> > folder.
>> > >> > >>>> > >>> ex. platforms/ios/ -> platforms/ios@4.0.1/
>> > >> > >>>> > >>>
>> > >> > >>>> > >>> 2. platforms/ios would always contain the latest ios
>> > version
>> > >> > >>>> installed
>> > >> > >>>> > for
>> > >> > >>>> > >>> this project. This would allow most tooling to work
>> > unchanged,
>> > >> > and
>> > >> > >>>> > >>> sidesteps symlink issues on windows with things like
>> > >> ios-latest
>> > >> > ->
>> > >> > >>>> > ios@4.02
>> > >> > >>>> > >>>
>> > >> > >>>> > >>> 3. [optional or stretch goal] 'platform rm ios' could be
>> > used
>> > >> to
>> > >> > >>>> go
>> > >> > >>>> > back to
>> > >> > >>>> > >>> the previous 'current' version ( according to semver )
>> or
>> > >> should
>> > >> > >>>> this
>> > >> > >>>> > be a
>> > >> > >>>> > >>> new command? like 'cordova platform pop ios' ?
>> > >> > >>>> > >>>
>> > >> > >>>> > >>> 4. we can add a flag to platform update ios --kill to
>> do a
>> > >> > >>>> destructive
>> > >> > >>>> > >>> update for users who know that that is what they want.
>> > >> > >>>> > >>>
>> > >> > >>>> > >>> 5. [optional | stretch ] allow build/run of platform
>> > artifacts
>> > >> > as
>> > >> > >>>> > well, so
>> > >> > >>>> > >>> developers can run commands like : 'cordova run
>> ios@4.0.1'
>> > >> > >>>> > >>>
>> > >> > >>>> > >>> 6. the platform listed in config.xml would always be the
>> > >> latest
>> > >> > >>>> one,
>> > >> > >>>> > >>> regardless of how many artifacts were still around.
>> > >> > >>>> > >>>
>> > >> > >>>> > >>> Thoughts? Issues? Comments?
>> > >> > >>>> > >>>
>> > >> > >>>> > >>>
>> > >> > >>>> > >>>
>> > >> > >>>> > >>>
>> > >> > >>>> > >>>
>> > >> > >>>> > >>>
>> > >> > >>>> > >>>
>> > >> > >>>> > >>>
>> > >> > >>>> > >>>
>> > >> > >>>> > >>>
>> > >> > >>>> > >>> @purplecabbage
>> > >> > >>>> > >>>
>> > >> > >>>> >
>> > >> > >>>>
>> > >> >
>> > >>
>> > https://na01.safelinks.protection.outlook.com/?url=risingj.
>> com&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e6
>> 4b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&
>> sdata=AYCfungKQfswLZClqFCBX2oacLlJixX8xOGAFiJjJcQ%3d
>> > >> > >>>> > >>>
>> > >> > >>>> > >>> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <
>> > >> > >>>> dan@cellartracker.com>
>> > >> > >>>> > wrote:
>> > >> > >>>> > >>>
>> > >> > >>>> > >>>> As a user of cordova (and list lurker), I thought I'd
>> > chime
>> > >> in
>> > >> > >>>> and say
>> > >> > >>>> > >>>> Carlos hit on some very good points. In theory I like
>> the
>> > >> idea
>> > >> > of
>> > >> > >>>> > treating
>> > >> > >>>> > >>>> platforms like build artifacts, but in reality -- at
>> least
>> > >> for
>> > >> > my
>> > >> > >>>> > current
>> > >> > >>>> > >>>> usage -- things are far from that. Making this type of
>> > change
>> > >> > >>>> will
>> > >> > >>>> > make my
>> > >> > >>>> > >>>> upgrades more challenging. I'm willing to live with
>> that,
>> > but
>> > >> > >>>> PLEASE
>> > >> > >>>> > make
>> > >> > >>>> > >>>> sure you do a backup (or tell the user to) "just in
>> case"
>> > >> > before
>> > >> > >>>> > nuking
>> > >> > >>>> > >>>> their directory.
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> Right now, I find I do more native (non CLI)
>> development
>> > on
>> > >> iOS
>> > >> > >>>> > compared
>> > >> > >>>> > >>>> to other platforms. I'd have to do a full inventory of
>> > all of
>> > >> > my
>> > >> > >>>> > native
>> > >> > >>>> > >>>> customizations, but as Carlos mentions it is a
>> combination
>> > >> of:
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> - working around bugs/limitations in the tools
>> > >> > >>>> > >>>> - additional AppDelegate customizations for native
>> > analytics
>> > >> > >>>> > libraries and
>> > >> > >>>> > >>>> error handling as our app is remotely hosted
>> > >> > >>>> > >>>> - the addition of dependencies as cocoapods
>> > >> > >>>> > >>>> - other build/plist customizations which are far
>> simpler
>> > to
>> > >> > >>>> modify
>> > >> > >>>> > >>>> directly, e.g. adding an entitlements file to support
>> > >> universal
>> > >> > >>>> > links, or
>> > >> > >>>> > >>>> adding ITSEncryptionExportComplianceCode to the plist
>> to
>> > >> > >>>> simplify app
>> > >> > >>>> > >>>> submissions
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> Anyway, please just keep in mind those of us who may be
>> > doing
>> > >> > >>>> things
>> > >> > >>>> > the
>> > >> > >>>> > >>>> "old way" as you move forward here.
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> Dan
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> -----Original Message-----
>> > >> > >>>> > >>>> From: Carlos Santana [mailto:csantana23@gmail.com]
>> > >> > >>>> > >>>> Sent: Tuesday, March 08, 2016 3:16 PM
>> > >> > >>>> > >>>> To: dev@cordova.apache.org
>> > >> > >>>> > >>>> Subject: Re: [PROPOSAL] 'cordova platform update' alias
>> > for
>> > >> rm,
>> > >> > >>>> add in
>> > >> > >>>> > >>>> cordova-ios
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> I was never a fan of the "platform update" command
>> since
>> > it
>> > >> was
>> > >> > >>>> not
>> > >> > >>>> > fully
>> > >> > >>>> > >>>> tested across the board.
>> > >> > >>>> > >>>> like all the permutations possible to/from upgrade.
>> > meaning
>> > >> > >>>> going for
>> > >> > >>>> > very
>> > >> > >>>> > >>>> old like 3.6 to 5.1
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> If we do this I think it will break a lot of people
>> that
>> > got
>> > >> > >>>> used to
>> > >> > >>>> > >>>> changing files inside platform/ios/ in terms of
>> changing
>> > >> XCode
>> > >> > >>>> > settings in
>> > >> > >>>> > >>>> pbxproj like:
>> > >> > >>>> > >>>> - use story board to launch app to be able to support
>> ipad
>> > >> pro
>> > >> > >>>> > >>>> - some initialization code in AppDelegate
>> > >> > >>>> > >>>> - Any native code they added like NativeUI to mix web
>> and
>> > >> > native
>> > >> > >>>> > >>>> - Changes to StoryBoard to adjust webview inside native
>> > view
>> > >> > >>>> > >>>> - Build and Signing settings in project or target in
>> XCode
>> > >> > >>>> > >>>> - Installation of cocoapods
>> > >> > >>>> > >>>> - Xcode Build phases scripts
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> Meaning that they will need to restore or generate all
>> > this
>> > >> > >>>> things
>> > >> > >>>> > with
>> > >> > >>>> > >>>> hooks or plugins.
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> I know that Darryl Pogue and Tommy have projects where
>> > they
>> > >> > can
>> > >> > >>>> > >>>> successfully treat platfforms folder as 100% build
>> > artifact
>> > >> > that
>> > >> > >>>> they
>> > >> > >>>> > can
>> > >> > >>>> > >>>> throw away. But to get there is not super easy
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> "platform update ios" has being scoped to only touch
>> the
>> > >> > >>>> CordovaLib
>> > >> > >>>> > xcode
>> > >> > >>>> > >>>> project, leaving the app xcode project not touched
>> that's
>> > why
>> > >> > >>>> it's
>> > >> > >>>> > being
>> > >> > >>>> > >>>> safe all along
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> What was the root cause of the recent problems with
>> 4.1.0
>> > for
>> > >> > >>>> update?
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> Maybe we can restrict update command to major version,
>> > >> meaning
>> > >> > >>>> going
>> > >> > >>>> > from
>> > >> > >>>> > >>>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> In the current release of the IBM MobileFirst, were we
>> > have a
>> > >> > >>>> CLI to
>> > >> > >>>> > wrap
>> > >> > >>>> > >>>> cordova commands we had a "$ mfp cordova platform
>> update"
>> > >> > >>>> > >>>> We took a backup of the platform folder and create a
>> zip
>> > >> with a
>> > >> > >>>> > timestamp
>> > >> > >>>> > >>>> (like ios_1457477724404.zip)
>> > >> > >>>> > >>>> We did this just in case the command was destructive
>> and
>> > user
>> > >> > >>>> didn't
>> > >> > >>>> > lost
>> > >> > >>>> > >>>> files just in case they didn't have all files
>> > >> checked-in/backup
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> So doing a backup would be good if we move forward with
>> > this
>> > >> > >>>> > destructive
>> > >> > >>>> > >>>> action of doing a platform remove
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <
>> > >> > >>>> byoungro.so@intel.com>
>> > >> > >>>> > wrote:
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>> > I second that. +1
>> > >> > >>>> > >>>> >
>> > >> > >>>> > >>>> > Byoungro So
>> > >> > >>>> > >>>> > SSG / DPD / Mobile Computing and Compilers
>> > >> > >>>> > >>>> > Intel Corporation
>> > >> > >>>> > >>>> >
>> > >> > >>>> > >>>> > From: Anis KADRI <anis.kadri@gmail.com<mailto:
>> > >> > >>>> anis.kadri@gmail.com
>> > >> > >>>> > >>
>> > >> > >>>> > >>>> > Reply-To: "dev@cordova.apache.org<mailto:
>> > >> > >>>> dev@cordova.apache.org>" <
>> > >> > >>>> > >>>> > dev@cordova.apache.org<mailto:dev@cordova.apache.org
>> >>
>> > >> > >>>> > >>>> > Date: Tuesday, March 8, 2016 at 2:34 PM
>> > >> > >>>> > >>>> > To: "dev@cordova.apache.org<mailto:
>> > dev@cordova.apache.org
>> > >> >"
>> > >> > <
>> > >> > >>>> > >>>> > dev@cordova.apache.org<mailto:dev@cordova.apache.org
>> >>
>> > >> > >>>> > >>>> > Subject: Re: [PROPOSAL] 'cordova platform update'
>> alias
>> > for
>> > >> > >>>> rm, add
>> > >> > >>>> > in
>> > >> > >>>> > >>>> > cordova-ios
>> > >> > >>>> > >>>> >
>> > >> > >>>> > >>>> > I support this as well. Real updates never work.
>> Better
>> > to
>> > >> > >>>> > remove/add.
>> > >> > >>>> > >>>> >
>> > >> > >>>> > >>>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <
>> > >> > >>>> stevengill97@gmail.com
>> > >> > >>>> > >>>> > <ma...@gmail.com>> wrote:
>> > >> > >>>> > >>>> >
>> > >> > >>>> > >>>> > I would also like to see this happen. Would this
>> cause
>> > >> > >>>> problems if
>> > >> > >>>> > we did
>> > >> > >>>> > >>>> > this for other platforms?
>> > >> > >>>> > >>>> >
>> > >> > >>>> > >>>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <
>> > >> shazron@gmail.com
>> > >> > >>>> <mailto:
>> > >> > >>>> > >>>> > shazron@gmail.com>> wrote:
>> > >> > >>>> > >>>> >
>> > >> > >>>> > >>>> > > See:
>> > >> > >>>> > >>>> > >
>> > >> > >>>> >
>> > >> > >>>>
>> > >> >
>> > >>
>> > https://na01.safelinks.protection.outlook.com/?url=https%3a%
>> 2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%
>> 7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d3
>> 4c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoB
>> ecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
>> > >> > >>>> > >>>> > >
>> > >> > >>>> > >>>> > > Problem:
>> > >> > >>>> > >>>> > > For cordova-ios, "cordova platform update" does its
>> > own
>> > >> > >>>> thing,
>> > >> > >>>> > which
>> > >> > >>>> > >>>> > > causes problems.
>> > >> > >>>> > >>>> > >
>> > >> > >>>> > >>>> > > Proposal:
>> > >> > >>>> > >>>> > > Change "cordova platform update ios@version" to be
>> > >> > >>>> basically an
>> > >> > >>>> > alias
>> > >> > >>>> > >>>> > for:
>> > >> > >>>> > >>>> > > "cordova platform rm ios"
>> > >> > >>>> > >>>> > > "cordova platform add ios@version"
>> > >> > >>>> > >>>> > >
>> > >> > >>>> > >>>> > >
>> > >> > >>>> >
>> > >> > ------------------------------------------------------------
>> ---------
>> > >> > >>>> > >>>> > > To unsubscribe, e-mail:
>> > >> dev-unsubscribe@cordova.apache.org
>> > >> > >>>> > <mailto:
>> > >> > >>>> > >>>> > dev-unsubscribe@cordova.apache.org>
>> > >> > >>>> > >>>> > > For additional commands, e-mail:
>> > >> > dev-help@cordova.apache.org
>> > >> > >>>> > <mailto:
>> > >> > >>>> > >>>> > dev-help@cordova.apache.org>
>> > >> > >>>> > >>>> > >
>> > >> > >>>> > >>>> > >
>> > >> > >>>> > >>>> >
>> > >> > >>>> > >>>> >
>> > >> > >>>> > >>>> >
>> > >> > >>>> > >>>> >
>> > >> > >>>> >
>> > >> > ------------------------------------------------------------
>> ---------
>> > >> > >>>> > >>>> > To unsubscribe, e-mail:
>> > dev-unsubscribe@cordova.apache.org
>> > >> > >>>> > >>>> > For additional commands, e-mail:
>> > >> dev-help@cordova.apache.org
>> > >> > >>>> > >>>> >
>> > >> > >>>> > >>>>
>> > >> > >>>> > >>>>
>> > >> > >>>>
>> > >> ------------------------------------------------------------
>> ---------
>> > >> > >>>> > >>>> To unsubscribe, e-mail:
>> > dev-unsubscribe@cordova.apache.org
>> > >> > >>>> > >>>> For additional commands, e-mail:
>> > dev-help@cordova.apache.org
>> > >> > >>>> > >>>>
>> > >> > >>>> > >
>> > >> > >>>> >
>> > >> > >-----------------------------------------------------------
>> ----------
>> > >> > >>>> > >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > >> > >>>> > >For additional commands, e-mail:
>> dev-help@cordova.apache.org
>> > >> > >>>> > >
>> > >> > >>>> >
>> > >> > >>>> >
>> > >> > >>>>
>> > >> > >>>
>> > >> >
>> > >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>> >
>>
>
>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Shazron <sh...@gmail.com>.
This has not been resolved yet. We'll discuss more next week.
Archive link to this thread just in case you don't have it:
https://lists.apache.org/thread.html/dfeaab003cf67e915e342ebbf3826888c3b604d151e01dbaf9ab9950@1457466905@%3Cdev.cordova.apache.org%3E
Jesse's proposal to help fix this:
https://github.com/cordova/cordova-discuss/issues/50
On Sun, Mar 20, 2016 at 12:06 PM, julio cesar sanchez <
jcesarmobile@gmail.com> wrote:
> Not sure how many people still uses the non CLI approach, but the
> phonegap.com tutorial for android embedded webviews it uses it.
>
> 2016-03-19 2:34 GMT+01:00 Shazron <sh...@gmail.com>:
>
> > Another issue: we still document the non-CLI way to update projects.
> > This was brought to my attention in a comment [1] in CB-10775.
> >
> > The platform specific way is still mentioned [2], and update
> > instructions for iOS [3] and android [4] still exist.
> >
> > I think we should not have any more "update" docs that don't involve
> > the CLI. What do you think?
> >
> > [1]
> > https://issues.apache.org/jira/browse/CB-10775?
> focusedCommentId=15200735&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-15200735
> > [2]
> > https://cordova.apache.org/docs/en/latest/guide/overview/
> index.html#development-paths
> > [3]
> > http://cordova.apache.org/docs/en/latest/guide/
> platforms/ios/upgrade.html
> > [4]
> > http://cordova.apache.org/docs/en/latest/guide/
> platforms/android/upgrade.html
> >
> >
> > On Wed, Mar 16, 2016 at 7:44 AM, Carlos Santana <cs...@gmail.com>
> > wrote:
> > > yep I agree Julio about adding more power to config.xml, that's
> > basically
> > > what Mike's hook those allow <config-file> tag in config.xml
> > >
> > >
> > > On Wed, Mar 16, 2016 at 10:23 AM julio cesar sanchez <
> > jcesarmobile@gmail.com>
> > > wrote:
> > >
> > >> I like Jesse's proposal
> > >>
> > >> for #3 I think we should use a new command, I like cordova *downgrade*
> > >> platform
> > >>
> > >> As I usually read most cordova questions on stackoverflow, most people
> > is
> > >> editing and tellign others to edit the .plist manually and doing some
> > other
> > >> manual changes. I always point them to use hooks or plugins to do
> that,
> > but
> > >> as it's harder they don't want to do it.
> > >>
> > >> BTW, I think we should add a way to write on the AndroidManifest.xml
> and
> > >> info.plist from the config.xml as phonegap build does, using the
> > >> config-file tag. Right now it's possible to use the config-file tag on
> > >> plugin.xml but not on config.xml
> > >>
> > >>
> > >>
> > >>
> > >> 2016-03-16 14:54 GMT+01:00 Carlos Santana <cs...@gmail.com>:
> > >>
> > >> > Here is an example [1] of hooks created by ionic team member
> extending
> > >> > config.xml to allow user to configure their native sdk settings
> > allowing
> > >> > have platforms as build artifacts.
> > >> >
> > >> > This could be a start at looking at some basic configuration
> settings
> > via
> > >> > hooks cordova provides or just in cordova tooling (i.e. platformAPI
> > >> parser)
> > >> >
> > >> > [1]: https://github.com/mhartington/cordova-config-utils
> > >> >
> > >> >
> > >> > On Tue, Mar 15, 2016 at 10:31 PM Carlos Santana <
> csantana23@gmail.com
> > >
> > >> > wrote:
> > >> >
> > >> > > Scratch the "migrate cli command" idea. Now I think about it
> really
> > >> messy
> > >> > > and it will be another hackHooks.
> > >> > >
> > >> > > I think we concentrate to provide more capabilities thru
> config.xml
> > and
> > >> > > hooks for making migration more smooth.
> > >> > >
> > >> > > Like a running hooks on after_platform_update event and providing
> > more
> > >> > > information in the hook context argument with from to platform
> info
> > >> > >
> > >> > >
> > >> > >
> > >> > > On Tue, Mar 15, 2016 at 9:52 PM Carlos Santana <
> > csantana23@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > >> By "I like the proposal and deleting all previous versions I
> don't
> > see
> > >> > as
> > >> > >> an issue." I meant that I don't have an issue if we don't have
> this
> > >> > feature
> > >> > >> to clean old. I prefer not to have it
> > >> > >>
> > >> > >> On Tue, Mar 15, 2016 at 9:51 PM Carlos Santana <
> > csantana23@gmail.com>
> > >> > >> wrote:
> > >> > >>
> > >> > >>> I like the proposal and deleting all previous versions I don't
> > see as
> > >> > an
> > >> > >>> issue.
> > >> > >>>
> > >> > >>> I didn't get the part of using symlinks, I don't symlinks they
> > bring
> > >> a
> > >> > >>> lot of problems to implement correctly I prefer we stick to real
> > >> > directory
> > >> > >>> and rename directories, user can choose to create symlinks on
> > their
> > >> > needs,
> > >> > >>> we would just handle them.
> > >> > >>>
> > >> > >>> If end up doing a flag I prefer just deleting the one being
> > replace,
> > >> as
> > >> > >>> --no-backup
> > >> > >>> cordova platform update ios --no-backup (using nopt notation)
> > >> > >>> will do the rename ios -> ios@4.0.1
> > >> > >>> will do the add ios
> > >> > >>> then only then if the add works and all plugins present get
> > install
> > >> and
> > >> > >>> cli exist with none zero go and don't save the backup and delete
> > the
> > >> > folder
> > >> > >>> that was rename to ios@4.0.1
> > >> > >>>
> > >> > >>> But I agree for now implement default to always do a backup, no
> > flag
> > >> > >>> (maybe experimental)
> > >> > >>>
> > >> > >>> User needs to be explicit on harmful actions, they can do
> > platform rm
> > >> > >>> ios@4.0.1 will simple delete /platforms/ios@4.0.1
> > >> > >>> and he can do it for any platform current/active or old backups
> > >> > >>>
> > >> > >>> I'm OK about this proposal and we can start a new one that
> covers
> > how
> > >> > to
> > >> > >>> help with migration. Since update becomes backup,
> > >> > >>> We need to think how much we invest in migration, value of
> > cordova is
> > >> > on
> > >> > >>> the runtime (core platform, and plugins)
> > >> > >>>
> > >> > >>> We can do start iterating with implementing enablement but
> > specific
> > >> > >>> migration tasks/actions are built on real experiences by the
> > >> community.
> > >> > >>> Meaning plugins/extensions that are plugable to handle
> migration,
> > >> today
> > >> > >>> peope do with hooks, I call those hackHooks :-), hooks that do
> > hacks
> > >> to
> > >> > >>> make platforms build artifacts and be able to restore everything
> > that
> > >> > can't
> > >> > >>> be restore with platform+plugins+config.xml
> > >> > >>>
> > >> > >>> So the flow I see if as the following:
> > >> > >>>
> > >> > >>> cordova platform update ios
> > >> > >>> ....
> > >> > >>> mv platforms/ios platforms/ios@4.0.1
> > >> > >>> add platforms/ios
> > >> > >>> ....
> > >> > >>> cordova migrate ios ios@4.0.1
> > >> > >>>
> > >> > >>> This cli migrate command migrate helps user migrate things from
> > 4.0.1
> > >> > >>> (ios@4.0.1) to 4.1 (ios/current)
> > >> > >>> migrate will run the actions/tasks/extensions added by the user,
> > this
> > >> > >>> actions/tasks/extensions (don't have a good name for migrations
> > >> > "things")
> > >> > >>> will be available on npm with keyword cordova:migrate
> > >> > >>> For example there can be a command "migrate add
> > >> > >>> cordova-migrate-entitlements" (this tasks migrate ios
> entitlements
> > >> > from an
> > >> > >>> old project to a new project)
> > >> > >>> this tasks/extension will be added to list of steps to do to
> > automate
> > >> > >>> migration when cli command migrate runs
> > >> > >>> Cordova project can provide the tooling and maybe a handful (or
> > zero)
> > >> > of
> > >> > >>> well known tasks for migration, but not more, the rest will come
> > from
> > >> > the
> > >> > >>> community/3rd party to maintain and publish, this will be a way
> > for
> > >> > people
> > >> > >>> like Darryl and Tommy that have knowledge on migration and hooks
> > they
> > >> > can
> > >> > >>> convert those to migration npm packages to share.
> > >> > >>>
> > >> > >>>
> > >> > >>>
> > >> > >>>
> > >> > >>>
> > >> > >>>
> > >> > >>> On Mon, Mar 14, 2016 at 8:21 PM Jesse <pu...@gmail.com>
> > >> wrote:
> > >> > >>>
> > >> > >>>> Yeah, the simple approach is probably the best!
> > >> > >>>>
> > >> > >>>> Move to strike --kill or any variation of it, and let
> developers
> > >> > delete
> > >> > >>>> what they want to. If it proves to be an issue, then we will
> > >> address
> > >> > >>>> it.
> > >> > >>>>
> > >> > >>>>
> > >> > >>>> @purplecabbage
> > >> > >>>> risingj.com
> > >> > >>>>
> > >> > >>>> On Mon, Mar 14, 2016 at 3:58 PM, Parashuram N <
> > >> panarasi@microsoft.com
> > >> > >
> > >> > >>>> wrote:
> > >> > >>>>
> > >> > >>>> > Instead of adding an entire flag to remove previous versions,
> > does
> > >> > it
> > >> > >>>> make
> > >> > >>>> > sense to have cordova platform android@oldVersion.
> > Alternatively,
> > >> > >>>> users
> > >> > >>>> > could simple use the terminal to delete older versions from
> the
> > >> > >>>> command
> > >> > >>>> > line inside the platform folders.
> > >> > >>>> > If we have users asking for a way to “remove all older
> > platforms”,
> > >> > we
> > >> > >>>> > could then introduce this flag.
> > >> > >>>> >
> > >> > >>>> > On 3/14/16, 2:07 PM, "Shazron" <sh...@gmail.com> wrote:
> > >> > >>>> >
> > >> > >>>> > >Note:
> > >> > >>>> > >I prefer `--remove-previous-versions` to `--kill` so as to
> be
> > >> > >>>> > >unambiguous and explicit.
> > >> > >>>> > >
> > >> > >>>> > >On Mon, Mar 14, 2016 at 2:01 PM, Shazron <shazron@gmail.com
> >
> > >> > wrote:
> > >> > >>>> > >> +1 I like it (esp reasons in #2)
> > >> > >>>> > >>
> > >> > >>>> > >> I agree that platform rm+add is not there yet, case in
> point
> > >> all
> > >> > >>>> the
> > >> > >>>> > >> related issues in the "Issue Links" in this issue:
> > >> > >>>> > >>
> > >> > >>>> >
> > >> > >>>>
> > >> >
> > >>
> > https://na01.safelinks.protection.outlook.com/?url=
> https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-
> 10775&data=01%7c01%7cpanarasi%40microsoft.com%
> 7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011
> db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
> > >> > >>>> > >>
> > >> > >>>> > >> Some comments:
> > >> > >>>> > >>
> > >> > >>>> > >> `cordova platform ls` should list these previous versions
> as
> > >> > well.
> > >> > >>>> > >>
> > >> > >>>> > >> `cordova platform add ios` should not delete these
> previous
> > >> > >>>> versions?
> > >> > >>>> > >>
> > >> > >>>> > >> `cordova platform update ios --kill` kills *all* previous
> > >> > versions,
> > >> > >>>> > >> regardless of major version (clarification)
> > >> > >>>> > >>
> > >> > >>>> > >> `cordova platform rm ios` should just remove the current
> > >> version
> > >> > >>>> so it
> > >> > >>>> > >> doesn't get confusing. If we have listing of the previous
> > >> > versions
> > >> > >>>> > >> above in `cordova platform ls`, you would have to
> explicitly
> > >> do a
> > >> > >>>> > >> `cordova platform rm ios@4.0.1` for example. However,
> this
> > >> does
> > >> > >>>> not
> > >> > >>>> > >> solve for a way to remove *all* previous versions (we will
> > have
> > >> > to
> > >> > >>>> > >> figure out a new command?)
> > >> > >>>> > >>
> > >> > >>>> > >>
> > >> > >>>> > >> On Mon, Mar 14, 2016 at 1:29 PM, Jesse <
> > >> purplecabbage@gmail.com>
> > >> > >>>> wrote:
> > >> > >>>> > >>> Considering all of the points previously mentioned, I
> would
> > >> like
> > >> > >>>> to
> > >> > >>>> > make a
> > >> > >>>> > >>> supplementary proposal.
> > >> > >>>> > >>>
> > >> > >>>> > >>> We seem to all agree that platform rm+add is ideal in a
> > world
> > >> > >>>> where we
> > >> > >>>> > can
> > >> > >>>> > >>> truly consider platforms as artifacts, but we are really
> > not
> > >> > >>>> there yet.
> > >> > >>>> > >>> The zipped snapshot of the platform before the update
> that
> > >> > Carlos
> > >> > >>>> > mentions
> > >> > >>>> > >>> is a good non-destructive way of allowing a developer the
> > >> chance
> > >> > >>>> to
> > >> > >>>> > always
> > >> > >>>> > >>> go back.
> > >> > >>>> > >>> I would like to take this approach one step further and
> > >> suggest:
> > >> > >>>> > >>> (note: I am using 'ios' as the example platform, but
> this
> > >> > >>>> applies to
> > >> > >>>> > >>> any/all platforms )
> > >> > >>>> > >>>
> > >> > >>>> > >>> 1. when updating a project, we rename the previous
> > >> > platforms/ios/
> > >> > >>>> to
> > >> > >>>> > >>> include the version it was, and leave it in the platforms
> > >> > folder.
> > >> > >>>> > >>> ex. platforms/ios/ -> platforms/ios@4.0.1/
> > >> > >>>> > >>>
> > >> > >>>> > >>> 2. platforms/ios would always contain the latest ios
> > version
> > >> > >>>> installed
> > >> > >>>> > for
> > >> > >>>> > >>> this project. This would allow most tooling to work
> > unchanged,
> > >> > and
> > >> > >>>> > >>> sidesteps symlink issues on windows with things like
> > >> ios-latest
> > >> > ->
> > >> > >>>> > ios@4.02
> > >> > >>>> > >>>
> > >> > >>>> > >>> 3. [optional or stretch goal] 'platform rm ios' could be
> > used
> > >> to
> > >> > >>>> go
> > >> > >>>> > back to
> > >> > >>>> > >>> the previous 'current' version ( according to semver ) or
> > >> should
> > >> > >>>> this
> > >> > >>>> > be a
> > >> > >>>> > >>> new command? like 'cordova platform pop ios' ?
> > >> > >>>> > >>>
> > >> > >>>> > >>> 4. we can add a flag to platform update ios --kill to do
> a
> > >> > >>>> destructive
> > >> > >>>> > >>> update for users who know that that is what they want.
> > >> > >>>> > >>>
> > >> > >>>> > >>> 5. [optional | stretch ] allow build/run of platform
> > artifacts
> > >> > as
> > >> > >>>> > well, so
> > >> > >>>> > >>> developers can run commands like : 'cordova run ios@4.0.1
> '
> > >> > >>>> > >>>
> > >> > >>>> > >>> 6. the platform listed in config.xml would always be the
> > >> latest
> > >> > >>>> one,
> > >> > >>>> > >>> regardless of how many artifacts were still around.
> > >> > >>>> > >>>
> > >> > >>>> > >>> Thoughts? Issues? Comments?
> > >> > >>>> > >>>
> > >> > >>>> > >>>
> > >> > >>>> > >>>
> > >> > >>>> > >>>
> > >> > >>>> > >>>
> > >> > >>>> > >>>
> > >> > >>>> > >>>
> > >> > >>>> > >>>
> > >> > >>>> > >>>
> > >> > >>>> > >>>
> > >> > >>>> > >>> @purplecabbage
> > >> > >>>> > >>>
> > >> > >>>> >
> > >> > >>>>
> > >> >
> > >>
> > https://na01.safelinks.protection.outlook.com/?url=
> risingj.com&data=01%7c01%7cpanarasi%40microsoft.com%
> 7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011
> db47%7c1&sdata=AYCfungKQfswLZClqFCBX2oacLlJixX8xOGAFiJjJcQ%3d
> > >> > >>>> > >>>
> > >> > >>>> > >>> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <
> > >> > >>>> dan@cellartracker.com>
> > >> > >>>> > wrote:
> > >> > >>>> > >>>
> > >> > >>>> > >>>> As a user of cordova (and list lurker), I thought I'd
> > chime
> > >> in
> > >> > >>>> and say
> > >> > >>>> > >>>> Carlos hit on some very good points. In theory I like
> the
> > >> idea
> > >> > of
> > >> > >>>> > treating
> > >> > >>>> > >>>> platforms like build artifacts, but in reality -- at
> least
> > >> for
> > >> > my
> > >> > >>>> > current
> > >> > >>>> > >>>> usage -- things are far from that. Making this type of
> > change
> > >> > >>>> will
> > >> > >>>> > make my
> > >> > >>>> > >>>> upgrades more challenging. I'm willing to live with
> that,
> > but
> > >> > >>>> PLEASE
> > >> > >>>> > make
> > >> > >>>> > >>>> sure you do a backup (or tell the user to) "just in
> case"
> > >> > before
> > >> > >>>> > nuking
> > >> > >>>> > >>>> their directory.
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> Right now, I find I do more native (non CLI) development
> > on
> > >> iOS
> > >> > >>>> > compared
> > >> > >>>> > >>>> to other platforms. I'd have to do a full inventory of
> > all of
> > >> > my
> > >> > >>>> > native
> > >> > >>>> > >>>> customizations, but as Carlos mentions it is a
> combination
> > >> of:
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> - working around bugs/limitations in the tools
> > >> > >>>> > >>>> - additional AppDelegate customizations for native
> > analytics
> > >> > >>>> > libraries and
> > >> > >>>> > >>>> error handling as our app is remotely hosted
> > >> > >>>> > >>>> - the addition of dependencies as cocoapods
> > >> > >>>> > >>>> - other build/plist customizations which are far simpler
> > to
> > >> > >>>> modify
> > >> > >>>> > >>>> directly, e.g. adding an entitlements file to support
> > >> universal
> > >> > >>>> > links, or
> > >> > >>>> > >>>> adding ITSEncryptionExportComplianceCode to the plist
> to
> > >> > >>>> simplify app
> > >> > >>>> > >>>> submissions
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> Anyway, please just keep in mind those of us who may be
> > doing
> > >> > >>>> things
> > >> > >>>> > the
> > >> > >>>> > >>>> "old way" as you move forward here.
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> Dan
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> -----Original Message-----
> > >> > >>>> > >>>> From: Carlos Santana [mailto:csantana23@gmail.com]
> > >> > >>>> > >>>> Sent: Tuesday, March 08, 2016 3:16 PM
> > >> > >>>> > >>>> To: dev@cordova.apache.org
> > >> > >>>> > >>>> Subject: Re: [PROPOSAL] 'cordova platform update' alias
> > for
> > >> rm,
> > >> > >>>> add in
> > >> > >>>> > >>>> cordova-ios
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> I was never a fan of the "platform update" command since
> > it
> > >> was
> > >> > >>>> not
> > >> > >>>> > fully
> > >> > >>>> > >>>> tested across the board.
> > >> > >>>> > >>>> like all the permutations possible to/from upgrade.
> > meaning
> > >> > >>>> going for
> > >> > >>>> > very
> > >> > >>>> > >>>> old like 3.6 to 5.1
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> If we do this I think it will break a lot of people that
> > got
> > >> > >>>> used to
> > >> > >>>> > >>>> changing files inside platform/ios/ in terms of changing
> > >> XCode
> > >> > >>>> > settings in
> > >> > >>>> > >>>> pbxproj like:
> > >> > >>>> > >>>> - use story board to launch app to be able to support
> ipad
> > >> pro
> > >> > >>>> > >>>> - some initialization code in AppDelegate
> > >> > >>>> > >>>> - Any native code they added like NativeUI to mix web
> and
> > >> > native
> > >> > >>>> > >>>> - Changes to StoryBoard to adjust webview inside native
> > view
> > >> > >>>> > >>>> - Build and Signing settings in project or target in
> XCode
> > >> > >>>> > >>>> - Installation of cocoapods
> > >> > >>>> > >>>> - Xcode Build phases scripts
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> Meaning that they will need to restore or generate all
> > this
> > >> > >>>> things
> > >> > >>>> > with
> > >> > >>>> > >>>> hooks or plugins.
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> I know that Darryl Pogue and Tommy have projects where
> > they
> > >> > can
> > >> > >>>> > >>>> successfully treat platfforms folder as 100% build
> > artifact
> > >> > that
> > >> > >>>> they
> > >> > >>>> > can
> > >> > >>>> > >>>> throw away. But to get there is not super easy
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> "platform update ios" has being scoped to only touch the
> > >> > >>>> CordovaLib
> > >> > >>>> > xcode
> > >> > >>>> > >>>> project, leaving the app xcode project not touched
> that's
> > why
> > >> > >>>> it's
> > >> > >>>> > being
> > >> > >>>> > >>>> safe all along
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> What was the root cause of the recent problems with
> 4.1.0
> > for
> > >> > >>>> update?
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> Maybe we can restrict update command to major version,
> > >> meaning
> > >> > >>>> going
> > >> > >>>> > from
> > >> > >>>> > >>>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> In the current release of the IBM MobileFirst, were we
> > have a
> > >> > >>>> CLI to
> > >> > >>>> > wrap
> > >> > >>>> > >>>> cordova commands we had a "$ mfp cordova platform
> update"
> > >> > >>>> > >>>> We took a backup of the platform folder and create a zip
> > >> with a
> > >> > >>>> > timestamp
> > >> > >>>> > >>>> (like ios_1457477724404.zip)
> > >> > >>>> > >>>> We did this just in case the command was destructive and
> > user
> > >> > >>>> didn't
> > >> > >>>> > lost
> > >> > >>>> > >>>> files just in case they didn't have all files
> > >> checked-in/backup
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> So doing a backup would be good if we move forward with
> > this
> > >> > >>>> > destructive
> > >> > >>>> > >>>> action of doing a platform remove
> > >> > >>>> > >>>>
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <
> > >> > >>>> byoungro.so@intel.com>
> > >> > >>>> > wrote:
> > >> > >>>> > >>>>
> > >> > >>>> > >>>> > I second that. +1
> > >> > >>>> > >>>> >
> > >> > >>>> > >>>> > Byoungro So
> > >> > >>>> > >>>> > SSG / DPD / Mobile Computing and Compilers
> > >> > >>>> > >>>> > Intel Corporation
> > >> > >>>> > >>>> >
> > >> > >>>> > >>>> > From: Anis KADRI <anis.kadri@gmail.com<mailto:
> > >> > >>>> anis.kadri@gmail.com
> > >> > >>>> > >>
> > >> > >>>> > >>>> > Reply-To: "dev@cordova.apache.org<mailto:
> > >> > >>>> dev@cordova.apache.org>" <
> > >> > >>>> > >>>> > dev@cordova.apache.org<mailto:dev@cordova.apache.org
> >>
> > >> > >>>> > >>>> > Date: Tuesday, March 8, 2016 at 2:34 PM
> > >> > >>>> > >>>> > To: "dev@cordova.apache.org<mailto:
> > dev@cordova.apache.org
> > >> >"
> > >> > <
> > >> > >>>> > >>>> > dev@cordova.apache.org<mailto:dev@cordova.apache.org
> >>
> > >> > >>>> > >>>> > Subject: Re: [PROPOSAL] 'cordova platform update'
> alias
> > for
> > >> > >>>> rm, add
> > >> > >>>> > in
> > >> > >>>> > >>>> > cordova-ios
> > >> > >>>> > >>>> >
> > >> > >>>> > >>>> > I support this as well. Real updates never work.
> Better
> > to
> > >> > >>>> > remove/add.
> > >> > >>>> > >>>> >
> > >> > >>>> > >>>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <
> > >> > >>>> stevengill97@gmail.com
> > >> > >>>> > >>>> > <ma...@gmail.com>> wrote:
> > >> > >>>> > >>>> >
> > >> > >>>> > >>>> > I would also like to see this happen. Would this cause
> > >> > >>>> problems if
> > >> > >>>> > we did
> > >> > >>>> > >>>> > this for other platforms?
> > >> > >>>> > >>>> >
> > >> > >>>> > >>>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <
> > >> shazron@gmail.com
> > >> > >>>> <mailto:
> > >> > >>>> > >>>> > shazron@gmail.com>> wrote:
> > >> > >>>> > >>>> >
> > >> > >>>> > >>>> > > See:
> > >> > >>>> > >>>> > >
> > >> > >>>> >
> > >> > >>>>
> > >> >
> > >>
> > https://na01.safelinks.protection.outlook.com/?url=
> https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-
> 10775&data=01%7c01%7cpanarasi%40microsoft.com%
> 7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011
> db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
> > >> > >>>> > >>>> > >
> > >> > >>>> > >>>> > > Problem:
> > >> > >>>> > >>>> > > For cordova-ios, "cordova platform update" does its
> > own
> > >> > >>>> thing,
> > >> > >>>> > which
> > >> > >>>> > >>>> > > causes problems.
> > >> > >>>> > >>>> > >
> > >> > >>>> > >>>> > > Proposal:
> > >> > >>>> > >>>> > > Change "cordova platform update ios@version" to be
> > >> > >>>> basically an
> > >> > >>>> > alias
> > >> > >>>> > >>>> > for:
> > >> > >>>> > >>>> > > "cordova platform rm ios"
> > >> > >>>> > >>>> > > "cordova platform add ios@version"
> > >> > >>>> > >>>> > >
> > >> > >>>> > >>>> > >
> > >> > >>>> >
> > >> > ------------------------------------------------------------
> ---------
> > >> > >>>> > >>>> > > To unsubscribe, e-mail:
> > >> dev-unsubscribe@cordova.apache.org
> > >> > >>>> > <mailto:
> > >> > >>>> > >>>> > dev-unsubscribe@cordova.apache.org>
> > >> > >>>> > >>>> > > For additional commands, e-mail:
> > >> > dev-help@cordova.apache.org
> > >> > >>>> > <mailto:
> > >> > >>>> > >>>> > dev-help@cordova.apache.org>
> > >> > >>>> > >>>> > >
> > >> > >>>> > >>>> > >
> > >> > >>>> > >>>> >
> > >> > >>>> > >>>> >
> > >> > >>>> > >>>> >
> > >> > >>>> > >>>> >
> > >> > >>>> >
> > >> > ------------------------------------------------------------
> ---------
> > >> > >>>> > >>>> > To unsubscribe, e-mail:
> > dev-unsubscribe@cordova.apache.org
> > >> > >>>> > >>>> > For additional commands, e-mail:
> > >> dev-help@cordova.apache.org
> > >> > >>>> > >>>> >
> > >> > >>>> > >>>>
> > >> > >>>> > >>>>
> > >> > >>>>
> > >> ---------------------------------------------------------------------
> > >> > >>>> > >>>> To unsubscribe, e-mail:
> > dev-unsubscribe@cordova.apache.org
> > >> > >>>> > >>>> For additional commands, e-mail:
> > dev-help@cordova.apache.org
> > >> > >>>> > >>>>
> > >> > >>>> > >
> > >> > >>>> >
> > >> > >-----------------------------------------------------------
> ----------
> > >> > >>>> > >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> > >>>> > >For additional commands, e-mail:
> dev-help@cordova.apache.org
> > >> > >>>> > >
> > >> > >>>> >
> > >> > >>>> >
> > >> > >>>>
> > >> > >>>
> > >> >
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by julio cesar sanchez <jc...@gmail.com>.
Not sure how many people still uses the non CLI approach, but the
phonegap.com tutorial for android embedded webviews it uses it.
2016-03-19 2:34 GMT+01:00 Shazron <sh...@gmail.com>:
> Another issue: we still document the non-CLI way to update projects.
> This was brought to my attention in a comment [1] in CB-10775.
>
> The platform specific way is still mentioned [2], and update
> instructions for iOS [3] and android [4] still exist.
>
> I think we should not have any more "update" docs that don't involve
> the CLI. What do you think?
>
> [1]
> https://issues.apache.org/jira/browse/CB-10775?focusedCommentId=15200735&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15200735
> [2]
> https://cordova.apache.org/docs/en/latest/guide/overview/index.html#development-paths
> [3]
> http://cordova.apache.org/docs/en/latest/guide/platforms/ios/upgrade.html
> [4]
> http://cordova.apache.org/docs/en/latest/guide/platforms/android/upgrade.html
>
>
> On Wed, Mar 16, 2016 at 7:44 AM, Carlos Santana <cs...@gmail.com>
> wrote:
> > yep I agree Julio about adding more power to config.xml, that's
> basically
> > what Mike's hook those allow <config-file> tag in config.xml
> >
> >
> > On Wed, Mar 16, 2016 at 10:23 AM julio cesar sanchez <
> jcesarmobile@gmail.com>
> > wrote:
> >
> >> I like Jesse's proposal
> >>
> >> for #3 I think we should use a new command, I like cordova *downgrade*
> >> platform
> >>
> >> As I usually read most cordova questions on stackoverflow, most people
> is
> >> editing and tellign others to edit the .plist manually and doing some
> other
> >> manual changes. I always point them to use hooks or plugins to do that,
> but
> >> as it's harder they don't want to do it.
> >>
> >> BTW, I think we should add a way to write on the AndroidManifest.xml and
> >> info.plist from the config.xml as phonegap build does, using the
> >> config-file tag. Right now it's possible to use the config-file tag on
> >> plugin.xml but not on config.xml
> >>
> >>
> >>
> >>
> >> 2016-03-16 14:54 GMT+01:00 Carlos Santana <cs...@gmail.com>:
> >>
> >> > Here is an example [1] of hooks created by ionic team member extending
> >> > config.xml to allow user to configure their native sdk settings
> allowing
> >> > have platforms as build artifacts.
> >> >
> >> > This could be a start at looking at some basic configuration settings
> via
> >> > hooks cordova provides or just in cordova tooling (i.e. platformAPI
> >> parser)
> >> >
> >> > [1]: https://github.com/mhartington/cordova-config-utils
> >> >
> >> >
> >> > On Tue, Mar 15, 2016 at 10:31 PM Carlos Santana <csantana23@gmail.com
> >
> >> > wrote:
> >> >
> >> > > Scratch the "migrate cli command" idea. Now I think about it really
> >> messy
> >> > > and it will be another hackHooks.
> >> > >
> >> > > I think we concentrate to provide more capabilities thru config.xml
> and
> >> > > hooks for making migration more smooth.
> >> > >
> >> > > Like a running hooks on after_platform_update event and providing
> more
> >> > > information in the hook context argument with from to platform info
> >> > >
> >> > >
> >> > >
> >> > > On Tue, Mar 15, 2016 at 9:52 PM Carlos Santana <
> csantana23@gmail.com>
> >> > > wrote:
> >> > >
> >> > >> By "I like the proposal and deleting all previous versions I don't
> see
> >> > as
> >> > >> an issue." I meant that I don't have an issue if we don't have this
> >> > feature
> >> > >> to clean old. I prefer not to have it
> >> > >>
> >> > >> On Tue, Mar 15, 2016 at 9:51 PM Carlos Santana <
> csantana23@gmail.com>
> >> > >> wrote:
> >> > >>
> >> > >>> I like the proposal and deleting all previous versions I don't
> see as
> >> > an
> >> > >>> issue.
> >> > >>>
> >> > >>> I didn't get the part of using symlinks, I don't symlinks they
> bring
> >> a
> >> > >>> lot of problems to implement correctly I prefer we stick to real
> >> > directory
> >> > >>> and rename directories, user can choose to create symlinks on
> their
> >> > needs,
> >> > >>> we would just handle them.
> >> > >>>
> >> > >>> If end up doing a flag I prefer just deleting the one being
> replace,
> >> as
> >> > >>> --no-backup
> >> > >>> cordova platform update ios --no-backup (using nopt notation)
> >> > >>> will do the rename ios -> ios@4.0.1
> >> > >>> will do the add ios
> >> > >>> then only then if the add works and all plugins present get
> install
> >> and
> >> > >>> cli exist with none zero go and don't save the backup and delete
> the
> >> > folder
> >> > >>> that was rename to ios@4.0.1
> >> > >>>
> >> > >>> But I agree for now implement default to always do a backup, no
> flag
> >> > >>> (maybe experimental)
> >> > >>>
> >> > >>> User needs to be explicit on harmful actions, they can do
> platform rm
> >> > >>> ios@4.0.1 will simple delete /platforms/ios@4.0.1
> >> > >>> and he can do it for any platform current/active or old backups
> >> > >>>
> >> > >>> I'm OK about this proposal and we can start a new one that covers
> how
> >> > to
> >> > >>> help with migration. Since update becomes backup,
> >> > >>> We need to think how much we invest in migration, value of
> cordova is
> >> > on
> >> > >>> the runtime (core platform, and plugins)
> >> > >>>
> >> > >>> We can do start iterating with implementing enablement but
> specific
> >> > >>> migration tasks/actions are built on real experiences by the
> >> community.
> >> > >>> Meaning plugins/extensions that are plugable to handle migration,
> >> today
> >> > >>> peope do with hooks, I call those hackHooks :-), hooks that do
> hacks
> >> to
> >> > >>> make platforms build artifacts and be able to restore everything
> that
> >> > can't
> >> > >>> be restore with platform+plugins+config.xml
> >> > >>>
> >> > >>> So the flow I see if as the following:
> >> > >>>
> >> > >>> cordova platform update ios
> >> > >>> ....
> >> > >>> mv platforms/ios platforms/ios@4.0.1
> >> > >>> add platforms/ios
> >> > >>> ....
> >> > >>> cordova migrate ios ios@4.0.1
> >> > >>>
> >> > >>> This cli migrate command migrate helps user migrate things from
> 4.0.1
> >> > >>> (ios@4.0.1) to 4.1 (ios/current)
> >> > >>> migrate will run the actions/tasks/extensions added by the user,
> this
> >> > >>> actions/tasks/extensions (don't have a good name for migrations
> >> > "things")
> >> > >>> will be available on npm with keyword cordova:migrate
> >> > >>> For example there can be a command "migrate add
> >> > >>> cordova-migrate-entitlements" (this tasks migrate ios entitlements
> >> > from an
> >> > >>> old project to a new project)
> >> > >>> this tasks/extension will be added to list of steps to do to
> automate
> >> > >>> migration when cli command migrate runs
> >> > >>> Cordova project can provide the tooling and maybe a handful (or
> zero)
> >> > of
> >> > >>> well known tasks for migration, but not more, the rest will come
> from
> >> > the
> >> > >>> community/3rd party to maintain and publish, this will be a way
> for
> >> > people
> >> > >>> like Darryl and Tommy that have knowledge on migration and hooks
> they
> >> > can
> >> > >>> convert those to migration npm packages to share.
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> On Mon, Mar 14, 2016 at 8:21 PM Jesse <pu...@gmail.com>
> >> wrote:
> >> > >>>
> >> > >>>> Yeah, the simple approach is probably the best!
> >> > >>>>
> >> > >>>> Move to strike --kill or any variation of it, and let developers
> >> > delete
> >> > >>>> what they want to. If it proves to be an issue, then we will
> >> address
> >> > >>>> it.
> >> > >>>>
> >> > >>>>
> >> > >>>> @purplecabbage
> >> > >>>> risingj.com
> >> > >>>>
> >> > >>>> On Mon, Mar 14, 2016 at 3:58 PM, Parashuram N <
> >> panarasi@microsoft.com
> >> > >
> >> > >>>> wrote:
> >> > >>>>
> >> > >>>> > Instead of adding an entire flag to remove previous versions,
> does
> >> > it
> >> > >>>> make
> >> > >>>> > sense to have cordova platform android@oldVersion.
> Alternatively,
> >> > >>>> users
> >> > >>>> > could simple use the terminal to delete older versions from the
> >> > >>>> command
> >> > >>>> > line inside the platform folders.
> >> > >>>> > If we have users asking for a way to “remove all older
> platforms”,
> >> > we
> >> > >>>> > could then introduce this flag.
> >> > >>>> >
> >> > >>>> > On 3/14/16, 2:07 PM, "Shazron" <sh...@gmail.com> wrote:
> >> > >>>> >
> >> > >>>> > >Note:
> >> > >>>> > >I prefer `--remove-previous-versions` to `--kill` so as to be
> >> > >>>> > >unambiguous and explicit.
> >> > >>>> > >
> >> > >>>> > >On Mon, Mar 14, 2016 at 2:01 PM, Shazron <sh...@gmail.com>
> >> > wrote:
> >> > >>>> > >> +1 I like it (esp reasons in #2)
> >> > >>>> > >>
> >> > >>>> > >> I agree that platform rm+add is not there yet, case in point
> >> all
> >> > >>>> the
> >> > >>>> > >> related issues in the "Issue Links" in this issue:
> >> > >>>> > >>
> >> > >>>> >
> >> > >>>>
> >> >
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
> >> > >>>> > >>
> >> > >>>> > >> Some comments:
> >> > >>>> > >>
> >> > >>>> > >> `cordova platform ls` should list these previous versions as
> >> > well.
> >> > >>>> > >>
> >> > >>>> > >> `cordova platform add ios` should not delete these previous
> >> > >>>> versions?
> >> > >>>> > >>
> >> > >>>> > >> `cordova platform update ios --kill` kills *all* previous
> >> > versions,
> >> > >>>> > >> regardless of major version (clarification)
> >> > >>>> > >>
> >> > >>>> > >> `cordova platform rm ios` should just remove the current
> >> version
> >> > >>>> so it
> >> > >>>> > >> doesn't get confusing. If we have listing of the previous
> >> > versions
> >> > >>>> > >> above in `cordova platform ls`, you would have to explicitly
> >> do a
> >> > >>>> > >> `cordova platform rm ios@4.0.1` for example. However, this
> >> does
> >> > >>>> not
> >> > >>>> > >> solve for a way to remove *all* previous versions (we will
> have
> >> > to
> >> > >>>> > >> figure out a new command?)
> >> > >>>> > >>
> >> > >>>> > >>
> >> > >>>> > >> On Mon, Mar 14, 2016 at 1:29 PM, Jesse <
> >> purplecabbage@gmail.com>
> >> > >>>> wrote:
> >> > >>>> > >>> Considering all of the points previously mentioned, I would
> >> like
> >> > >>>> to
> >> > >>>> > make a
> >> > >>>> > >>> supplementary proposal.
> >> > >>>> > >>>
> >> > >>>> > >>> We seem to all agree that platform rm+add is ideal in a
> world
> >> > >>>> where we
> >> > >>>> > can
> >> > >>>> > >>> truly consider platforms as artifacts, but we are really
> not
> >> > >>>> there yet.
> >> > >>>> > >>> The zipped snapshot of the platform before the update that
> >> > Carlos
> >> > >>>> > mentions
> >> > >>>> > >>> is a good non-destructive way of allowing a developer the
> >> chance
> >> > >>>> to
> >> > >>>> > always
> >> > >>>> > >>> go back.
> >> > >>>> > >>> I would like to take this approach one step further and
> >> suggest:
> >> > >>>> > >>> (note: I am using 'ios' as the example platform, but this
> >> > >>>> applies to
> >> > >>>> > >>> any/all platforms )
> >> > >>>> > >>>
> >> > >>>> > >>> 1. when updating a project, we rename the previous
> >> > platforms/ios/
> >> > >>>> to
> >> > >>>> > >>> include the version it was, and leave it in the platforms
> >> > folder.
> >> > >>>> > >>> ex. platforms/ios/ -> platforms/ios@4.0.1/
> >> > >>>> > >>>
> >> > >>>> > >>> 2. platforms/ios would always contain the latest ios
> version
> >> > >>>> installed
> >> > >>>> > for
> >> > >>>> > >>> this project. This would allow most tooling to work
> unchanged,
> >> > and
> >> > >>>> > >>> sidesteps symlink issues on windows with things like
> >> ios-latest
> >> > ->
> >> > >>>> > ios@4.02
> >> > >>>> > >>>
> >> > >>>> > >>> 3. [optional or stretch goal] 'platform rm ios' could be
> used
> >> to
> >> > >>>> go
> >> > >>>> > back to
> >> > >>>> > >>> the previous 'current' version ( according to semver ) or
> >> should
> >> > >>>> this
> >> > >>>> > be a
> >> > >>>> > >>> new command? like 'cordova platform pop ios' ?
> >> > >>>> > >>>
> >> > >>>> > >>> 4. we can add a flag to platform update ios --kill to do a
> >> > >>>> destructive
> >> > >>>> > >>> update for users who know that that is what they want.
> >> > >>>> > >>>
> >> > >>>> > >>> 5. [optional | stretch ] allow build/run of platform
> artifacts
> >> > as
> >> > >>>> > well, so
> >> > >>>> > >>> developers can run commands like : 'cordova run ios@4.0.1'
> >> > >>>> > >>>
> >> > >>>> > >>> 6. the platform listed in config.xml would always be the
> >> latest
> >> > >>>> one,
> >> > >>>> > >>> regardless of how many artifacts were still around.
> >> > >>>> > >>>
> >> > >>>> > >>> Thoughts? Issues? Comments?
> >> > >>>> > >>>
> >> > >>>> > >>>
> >> > >>>> > >>>
> >> > >>>> > >>>
> >> > >>>> > >>>
> >> > >>>> > >>>
> >> > >>>> > >>>
> >> > >>>> > >>>
> >> > >>>> > >>>
> >> > >>>> > >>>
> >> > >>>> > >>> @purplecabbage
> >> > >>>> > >>>
> >> > >>>> >
> >> > >>>>
> >> >
> >>
> https://na01.safelinks.protection.outlook.com/?url=risingj.com&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AYCfungKQfswLZClqFCBX2oacLlJixX8xOGAFiJjJcQ%3d
> >> > >>>> > >>>
> >> > >>>> > >>> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <
> >> > >>>> dan@cellartracker.com>
> >> > >>>> > wrote:
> >> > >>>> > >>>
> >> > >>>> > >>>> As a user of cordova (and list lurker), I thought I'd
> chime
> >> in
> >> > >>>> and say
> >> > >>>> > >>>> Carlos hit on some very good points. In theory I like the
> >> idea
> >> > of
> >> > >>>> > treating
> >> > >>>> > >>>> platforms like build artifacts, but in reality -- at least
> >> for
> >> > my
> >> > >>>> > current
> >> > >>>> > >>>> usage -- things are far from that. Making this type of
> change
> >> > >>>> will
> >> > >>>> > make my
> >> > >>>> > >>>> upgrades more challenging. I'm willing to live with that,
> but
> >> > >>>> PLEASE
> >> > >>>> > make
> >> > >>>> > >>>> sure you do a backup (or tell the user to) "just in case"
> >> > before
> >> > >>>> > nuking
> >> > >>>> > >>>> their directory.
> >> > >>>> > >>>>
> >> > >>>> > >>>> Right now, I find I do more native (non CLI) development
> on
> >> iOS
> >> > >>>> > compared
> >> > >>>> > >>>> to other platforms. I'd have to do a full inventory of
> all of
> >> > my
> >> > >>>> > native
> >> > >>>> > >>>> customizations, but as Carlos mentions it is a combination
> >> of:
> >> > >>>> > >>>>
> >> > >>>> > >>>> - working around bugs/limitations in the tools
> >> > >>>> > >>>> - additional AppDelegate customizations for native
> analytics
> >> > >>>> > libraries and
> >> > >>>> > >>>> error handling as our app is remotely hosted
> >> > >>>> > >>>> - the addition of dependencies as cocoapods
> >> > >>>> > >>>> - other build/plist customizations which are far simpler
> to
> >> > >>>> modify
> >> > >>>> > >>>> directly, e.g. adding an entitlements file to support
> >> universal
> >> > >>>> > links, or
> >> > >>>> > >>>> adding ITSEncryptionExportComplianceCode to the plist to
> >> > >>>> simplify app
> >> > >>>> > >>>> submissions
> >> > >>>> > >>>>
> >> > >>>> > >>>> Anyway, please just keep in mind those of us who may be
> doing
> >> > >>>> things
> >> > >>>> > the
> >> > >>>> > >>>> "old way" as you move forward here.
> >> > >>>> > >>>>
> >> > >>>> > >>>> Dan
> >> > >>>> > >>>>
> >> > >>>> > >>>> -----Original Message-----
> >> > >>>> > >>>> From: Carlos Santana [mailto:csantana23@gmail.com]
> >> > >>>> > >>>> Sent: Tuesday, March 08, 2016 3:16 PM
> >> > >>>> > >>>> To: dev@cordova.apache.org
> >> > >>>> > >>>> Subject: Re: [PROPOSAL] 'cordova platform update' alias
> for
> >> rm,
> >> > >>>> add in
> >> > >>>> > >>>> cordova-ios
> >> > >>>> > >>>>
> >> > >>>> > >>>> I was never a fan of the "platform update" command since
> it
> >> was
> >> > >>>> not
> >> > >>>> > fully
> >> > >>>> > >>>> tested across the board.
> >> > >>>> > >>>> like all the permutations possible to/from upgrade.
> meaning
> >> > >>>> going for
> >> > >>>> > very
> >> > >>>> > >>>> old like 3.6 to 5.1
> >> > >>>> > >>>>
> >> > >>>> > >>>> If we do this I think it will break a lot of people that
> got
> >> > >>>> used to
> >> > >>>> > >>>> changing files inside platform/ios/ in terms of changing
> >> XCode
> >> > >>>> > settings in
> >> > >>>> > >>>> pbxproj like:
> >> > >>>> > >>>> - use story board to launch app to be able to support ipad
> >> pro
> >> > >>>> > >>>> - some initialization code in AppDelegate
> >> > >>>> > >>>> - Any native code they added like NativeUI to mix web and
> >> > native
> >> > >>>> > >>>> - Changes to StoryBoard to adjust webview inside native
> view
> >> > >>>> > >>>> - Build and Signing settings in project or target in XCode
> >> > >>>> > >>>> - Installation of cocoapods
> >> > >>>> > >>>> - Xcode Build phases scripts
> >> > >>>> > >>>>
> >> > >>>> > >>>> Meaning that they will need to restore or generate all
> this
> >> > >>>> things
> >> > >>>> > with
> >> > >>>> > >>>> hooks or plugins.
> >> > >>>> > >>>>
> >> > >>>> > >>>> I know that Darryl Pogue and Tommy have projects where
> they
> >> > can
> >> > >>>> > >>>> successfully treat platfforms folder as 100% build
> artifact
> >> > that
> >> > >>>> they
> >> > >>>> > can
> >> > >>>> > >>>> throw away. But to get there is not super easy
> >> > >>>> > >>>>
> >> > >>>> > >>>> "platform update ios" has being scoped to only touch the
> >> > >>>> CordovaLib
> >> > >>>> > xcode
> >> > >>>> > >>>> project, leaving the app xcode project not touched that's
> why
> >> > >>>> it's
> >> > >>>> > being
> >> > >>>> > >>>> safe all along
> >> > >>>> > >>>>
> >> > >>>> > >>>> What was the root cause of the recent problems with 4.1.0
> for
> >> > >>>> update?
> >> > >>>> > >>>>
> >> > >>>> > >>>> Maybe we can restrict update command to major version,
> >> meaning
> >> > >>>> going
> >> > >>>> > from
> >> > >>>> > >>>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
> >> > >>>> > >>>>
> >> > >>>> > >>>> In the current release of the IBM MobileFirst, were we
> have a
> >> > >>>> CLI to
> >> > >>>> > wrap
> >> > >>>> > >>>> cordova commands we had a "$ mfp cordova platform update"
> >> > >>>> > >>>> We took a backup of the platform folder and create a zip
> >> with a
> >> > >>>> > timestamp
> >> > >>>> > >>>> (like ios_1457477724404.zip)
> >> > >>>> > >>>> We did this just in case the command was destructive and
> user
> >> > >>>> didn't
> >> > >>>> > lost
> >> > >>>> > >>>> files just in case they didn't have all files
> >> checked-in/backup
> >> > >>>> > >>>>
> >> > >>>> > >>>> So doing a backup would be good if we move forward with
> this
> >> > >>>> > destructive
> >> > >>>> > >>>> action of doing a platform remove
> >> > >>>> > >>>>
> >> > >>>> > >>>>
> >> > >>>> > >>>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <
> >> > >>>> byoungro.so@intel.com>
> >> > >>>> > wrote:
> >> > >>>> > >>>>
> >> > >>>> > >>>> > I second that. +1
> >> > >>>> > >>>> >
> >> > >>>> > >>>> > Byoungro So
> >> > >>>> > >>>> > SSG / DPD / Mobile Computing and Compilers
> >> > >>>> > >>>> > Intel Corporation
> >> > >>>> > >>>> >
> >> > >>>> > >>>> > From: Anis KADRI <anis.kadri@gmail.com<mailto:
> >> > >>>> anis.kadri@gmail.com
> >> > >>>> > >>
> >> > >>>> > >>>> > Reply-To: "dev@cordova.apache.org<mailto:
> >> > >>>> dev@cordova.apache.org>" <
> >> > >>>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> >> > >>>> > >>>> > Date: Tuesday, March 8, 2016 at 2:34 PM
> >> > >>>> > >>>> > To: "dev@cordova.apache.org<mailto:
> dev@cordova.apache.org
> >> >"
> >> > <
> >> > >>>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> >> > >>>> > >>>> > Subject: Re: [PROPOSAL] 'cordova platform update' alias
> for
> >> > >>>> rm, add
> >> > >>>> > in
> >> > >>>> > >>>> > cordova-ios
> >> > >>>> > >>>> >
> >> > >>>> > >>>> > I support this as well. Real updates never work. Better
> to
> >> > >>>> > remove/add.
> >> > >>>> > >>>> >
> >> > >>>> > >>>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <
> >> > >>>> stevengill97@gmail.com
> >> > >>>> > >>>> > <ma...@gmail.com>> wrote:
> >> > >>>> > >>>> >
> >> > >>>> > >>>> > I would also like to see this happen. Would this cause
> >> > >>>> problems if
> >> > >>>> > we did
> >> > >>>> > >>>> > this for other platforms?
> >> > >>>> > >>>> >
> >> > >>>> > >>>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <
> >> shazron@gmail.com
> >> > >>>> <mailto:
> >> > >>>> > >>>> > shazron@gmail.com>> wrote:
> >> > >>>> > >>>> >
> >> > >>>> > >>>> > > See:
> >> > >>>> > >>>> > >
> >> > >>>> >
> >> > >>>>
> >> >
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
> >> > >>>> > >>>> > >
> >> > >>>> > >>>> > > Problem:
> >> > >>>> > >>>> > > For cordova-ios, "cordova platform update" does its
> own
> >> > >>>> thing,
> >> > >>>> > which
> >> > >>>> > >>>> > > causes problems.
> >> > >>>> > >>>> > >
> >> > >>>> > >>>> > > Proposal:
> >> > >>>> > >>>> > > Change "cordova platform update ios@version" to be
> >> > >>>> basically an
> >> > >>>> > alias
> >> > >>>> > >>>> > for:
> >> > >>>> > >>>> > > "cordova platform rm ios"
> >> > >>>> > >>>> > > "cordova platform add ios@version"
> >> > >>>> > >>>> > >
> >> > >>>> > >>>> > >
> >> > >>>> >
> >> > ---------------------------------------------------------------------
> >> > >>>> > >>>> > > To unsubscribe, e-mail:
> >> dev-unsubscribe@cordova.apache.org
> >> > >>>> > <mailto:
> >> > >>>> > >>>> > dev-unsubscribe@cordova.apache.org>
> >> > >>>> > >>>> > > For additional commands, e-mail:
> >> > dev-help@cordova.apache.org
> >> > >>>> > <mailto:
> >> > >>>> > >>>> > dev-help@cordova.apache.org>
> >> > >>>> > >>>> > >
> >> > >>>> > >>>> > >
> >> > >>>> > >>>> >
> >> > >>>> > >>>> >
> >> > >>>> > >>>> >
> >> > >>>> > >>>> >
> >> > >>>> >
> >> > ---------------------------------------------------------------------
> >> > >>>> > >>>> > To unsubscribe, e-mail:
> dev-unsubscribe@cordova.apache.org
> >> > >>>> > >>>> > For additional commands, e-mail:
> >> dev-help@cordova.apache.org
> >> > >>>> > >>>> >
> >> > >>>> > >>>>
> >> > >>>> > >>>>
> >> > >>>>
> >> ---------------------------------------------------------------------
> >> > >>>> > >>>> To unsubscribe, e-mail:
> dev-unsubscribe@cordova.apache.org
> >> > >>>> > >>>> For additional commands, e-mail:
> dev-help@cordova.apache.org
> >> > >>>> > >>>>
> >> > >>>> > >
> >> > >>>> >
> >> > >---------------------------------------------------------------------
> >> > >>>> > >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> > >>>> > >For additional commands, e-mail: dev-help@cordova.apache.org
> >> > >>>> > >
> >> > >>>> >
> >> > >>>> >
> >> > >>>>
> >> > >>>
> >> >
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Shazron <sh...@gmail.com>.
Another issue: we still document the non-CLI way to update projects.
This was brought to my attention in a comment [1] in CB-10775.
The platform specific way is still mentioned [2], and update
instructions for iOS [3] and android [4] still exist.
I think we should not have any more "update" docs that don't involve
the CLI. What do you think?
[1] https://issues.apache.org/jira/browse/CB-10775?focusedCommentId=15200735&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15200735
[2] https://cordova.apache.org/docs/en/latest/guide/overview/index.html#development-paths
[3] http://cordova.apache.org/docs/en/latest/guide/platforms/ios/upgrade.html
[4] http://cordova.apache.org/docs/en/latest/guide/platforms/android/upgrade.html
On Wed, Mar 16, 2016 at 7:44 AM, Carlos Santana <cs...@gmail.com> wrote:
> yep I agree Julio about adding more power to config.xml, that's basically
> what Mike's hook those allow <config-file> tag in config.xml
>
>
> On Wed, Mar 16, 2016 at 10:23 AM julio cesar sanchez <jc...@gmail.com>
> wrote:
>
>> I like Jesse's proposal
>>
>> for #3 I think we should use a new command, I like cordova *downgrade*
>> platform
>>
>> As I usually read most cordova questions on stackoverflow, most people is
>> editing and tellign others to edit the .plist manually and doing some other
>> manual changes. I always point them to use hooks or plugins to do that, but
>> as it's harder they don't want to do it.
>>
>> BTW, I think we should add a way to write on the AndroidManifest.xml and
>> info.plist from the config.xml as phonegap build does, using the
>> config-file tag. Right now it's possible to use the config-file tag on
>> plugin.xml but not on config.xml
>>
>>
>>
>>
>> 2016-03-16 14:54 GMT+01:00 Carlos Santana <cs...@gmail.com>:
>>
>> > Here is an example [1] of hooks created by ionic team member extending
>> > config.xml to allow user to configure their native sdk settings allowing
>> > have platforms as build artifacts.
>> >
>> > This could be a start at looking at some basic configuration settings via
>> > hooks cordova provides or just in cordova tooling (i.e. platformAPI
>> parser)
>> >
>> > [1]: https://github.com/mhartington/cordova-config-utils
>> >
>> >
>> > On Tue, Mar 15, 2016 at 10:31 PM Carlos Santana <cs...@gmail.com>
>> > wrote:
>> >
>> > > Scratch the "migrate cli command" idea. Now I think about it really
>> messy
>> > > and it will be another hackHooks.
>> > >
>> > > I think we concentrate to provide more capabilities thru config.xml and
>> > > hooks for making migration more smooth.
>> > >
>> > > Like a running hooks on after_platform_update event and providing more
>> > > information in the hook context argument with from to platform info
>> > >
>> > >
>> > >
>> > > On Tue, Mar 15, 2016 at 9:52 PM Carlos Santana <cs...@gmail.com>
>> > > wrote:
>> > >
>> > >> By "I like the proposal and deleting all previous versions I don't see
>> > as
>> > >> an issue." I meant that I don't have an issue if we don't have this
>> > feature
>> > >> to clean old. I prefer not to have it
>> > >>
>> > >> On Tue, Mar 15, 2016 at 9:51 PM Carlos Santana <cs...@gmail.com>
>> > >> wrote:
>> > >>
>> > >>> I like the proposal and deleting all previous versions I don't see as
>> > an
>> > >>> issue.
>> > >>>
>> > >>> I didn't get the part of using symlinks, I don't symlinks they bring
>> a
>> > >>> lot of problems to implement correctly I prefer we stick to real
>> > directory
>> > >>> and rename directories, user can choose to create symlinks on their
>> > needs,
>> > >>> we would just handle them.
>> > >>>
>> > >>> If end up doing a flag I prefer just deleting the one being replace,
>> as
>> > >>> --no-backup
>> > >>> cordova platform update ios --no-backup (using nopt notation)
>> > >>> will do the rename ios -> ios@4.0.1
>> > >>> will do the add ios
>> > >>> then only then if the add works and all plugins present get install
>> and
>> > >>> cli exist with none zero go and don't save the backup and delete the
>> > folder
>> > >>> that was rename to ios@4.0.1
>> > >>>
>> > >>> But I agree for now implement default to always do a backup, no flag
>> > >>> (maybe experimental)
>> > >>>
>> > >>> User needs to be explicit on harmful actions, they can do platform rm
>> > >>> ios@4.0.1 will simple delete /platforms/ios@4.0.1
>> > >>> and he can do it for any platform current/active or old backups
>> > >>>
>> > >>> I'm OK about this proposal and we can start a new one that covers how
>> > to
>> > >>> help with migration. Since update becomes backup,
>> > >>> We need to think how much we invest in migration, value of cordova is
>> > on
>> > >>> the runtime (core platform, and plugins)
>> > >>>
>> > >>> We can do start iterating with implementing enablement but specific
>> > >>> migration tasks/actions are built on real experiences by the
>> community.
>> > >>> Meaning plugins/extensions that are plugable to handle migration,
>> today
>> > >>> peope do with hooks, I call those hackHooks :-), hooks that do hacks
>> to
>> > >>> make platforms build artifacts and be able to restore everything that
>> > can't
>> > >>> be restore with platform+plugins+config.xml
>> > >>>
>> > >>> So the flow I see if as the following:
>> > >>>
>> > >>> cordova platform update ios
>> > >>> ....
>> > >>> mv platforms/ios platforms/ios@4.0.1
>> > >>> add platforms/ios
>> > >>> ....
>> > >>> cordova migrate ios ios@4.0.1
>> > >>>
>> > >>> This cli migrate command migrate helps user migrate things from 4.0.1
>> > >>> (ios@4.0.1) to 4.1 (ios/current)
>> > >>> migrate will run the actions/tasks/extensions added by the user, this
>> > >>> actions/tasks/extensions (don't have a good name for migrations
>> > "things")
>> > >>> will be available on npm with keyword cordova:migrate
>> > >>> For example there can be a command "migrate add
>> > >>> cordova-migrate-entitlements" (this tasks migrate ios entitlements
>> > from an
>> > >>> old project to a new project)
>> > >>> this tasks/extension will be added to list of steps to do to automate
>> > >>> migration when cli command migrate runs
>> > >>> Cordova project can provide the tooling and maybe a handful (or zero)
>> > of
>> > >>> well known tasks for migration, but not more, the rest will come from
>> > the
>> > >>> community/3rd party to maintain and publish, this will be a way for
>> > people
>> > >>> like Darryl and Tommy that have knowledge on migration and hooks they
>> > can
>> > >>> convert those to migration npm packages to share.
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> On Mon, Mar 14, 2016 at 8:21 PM Jesse <pu...@gmail.com>
>> wrote:
>> > >>>
>> > >>>> Yeah, the simple approach is probably the best!
>> > >>>>
>> > >>>> Move to strike --kill or any variation of it, and let developers
>> > delete
>> > >>>> what they want to. If it proves to be an issue, then we will
>> address
>> > >>>> it.
>> > >>>>
>> > >>>>
>> > >>>> @purplecabbage
>> > >>>> risingj.com
>> > >>>>
>> > >>>> On Mon, Mar 14, 2016 at 3:58 PM, Parashuram N <
>> panarasi@microsoft.com
>> > >
>> > >>>> wrote:
>> > >>>>
>> > >>>> > Instead of adding an entire flag to remove previous versions, does
>> > it
>> > >>>> make
>> > >>>> > sense to have cordova platform android@oldVersion. Alternatively,
>> > >>>> users
>> > >>>> > could simple use the terminal to delete older versions from the
>> > >>>> command
>> > >>>> > line inside the platform folders.
>> > >>>> > If we have users asking for a way to “remove all older platforms”,
>> > we
>> > >>>> > could then introduce this flag.
>> > >>>> >
>> > >>>> > On 3/14/16, 2:07 PM, "Shazron" <sh...@gmail.com> wrote:
>> > >>>> >
>> > >>>> > >Note:
>> > >>>> > >I prefer `--remove-previous-versions` to `--kill` so as to be
>> > >>>> > >unambiguous and explicit.
>> > >>>> > >
>> > >>>> > >On Mon, Mar 14, 2016 at 2:01 PM, Shazron <sh...@gmail.com>
>> > wrote:
>> > >>>> > >> +1 I like it (esp reasons in #2)
>> > >>>> > >>
>> > >>>> > >> I agree that platform rm+add is not there yet, case in point
>> all
>> > >>>> the
>> > >>>> > >> related issues in the "Issue Links" in this issue:
>> > >>>> > >>
>> > >>>> >
>> > >>>>
>> >
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
>> > >>>> > >>
>> > >>>> > >> Some comments:
>> > >>>> > >>
>> > >>>> > >> `cordova platform ls` should list these previous versions as
>> > well.
>> > >>>> > >>
>> > >>>> > >> `cordova platform add ios` should not delete these previous
>> > >>>> versions?
>> > >>>> > >>
>> > >>>> > >> `cordova platform update ios --kill` kills *all* previous
>> > versions,
>> > >>>> > >> regardless of major version (clarification)
>> > >>>> > >>
>> > >>>> > >> `cordova platform rm ios` should just remove the current
>> version
>> > >>>> so it
>> > >>>> > >> doesn't get confusing. If we have listing of the previous
>> > versions
>> > >>>> > >> above in `cordova platform ls`, you would have to explicitly
>> do a
>> > >>>> > >> `cordova platform rm ios@4.0.1` for example. However, this
>> does
>> > >>>> not
>> > >>>> > >> solve for a way to remove *all* previous versions (we will have
>> > to
>> > >>>> > >> figure out a new command?)
>> > >>>> > >>
>> > >>>> > >>
>> > >>>> > >> On Mon, Mar 14, 2016 at 1:29 PM, Jesse <
>> purplecabbage@gmail.com>
>> > >>>> wrote:
>> > >>>> > >>> Considering all of the points previously mentioned, I would
>> like
>> > >>>> to
>> > >>>> > make a
>> > >>>> > >>> supplementary proposal.
>> > >>>> > >>>
>> > >>>> > >>> We seem to all agree that platform rm+add is ideal in a world
>> > >>>> where we
>> > >>>> > can
>> > >>>> > >>> truly consider platforms as artifacts, but we are really not
>> > >>>> there yet.
>> > >>>> > >>> The zipped snapshot of the platform before the update that
>> > Carlos
>> > >>>> > mentions
>> > >>>> > >>> is a good non-destructive way of allowing a developer the
>> chance
>> > >>>> to
>> > >>>> > always
>> > >>>> > >>> go back.
>> > >>>> > >>> I would like to take this approach one step further and
>> suggest:
>> > >>>> > >>> (note: I am using 'ios' as the example platform, but this
>> > >>>> applies to
>> > >>>> > >>> any/all platforms )
>> > >>>> > >>>
>> > >>>> > >>> 1. when updating a project, we rename the previous
>> > platforms/ios/
>> > >>>> to
>> > >>>> > >>> include the version it was, and leave it in the platforms
>> > folder.
>> > >>>> > >>> ex. platforms/ios/ -> platforms/ios@4.0.1/
>> > >>>> > >>>
>> > >>>> > >>> 2. platforms/ios would always contain the latest ios version
>> > >>>> installed
>> > >>>> > for
>> > >>>> > >>> this project. This would allow most tooling to work unchanged,
>> > and
>> > >>>> > >>> sidesteps symlink issues on windows with things like
>> ios-latest
>> > ->
>> > >>>> > ios@4.02
>> > >>>> > >>>
>> > >>>> > >>> 3. [optional or stretch goal] 'platform rm ios' could be used
>> to
>> > >>>> go
>> > >>>> > back to
>> > >>>> > >>> the previous 'current' version ( according to semver ) or
>> should
>> > >>>> this
>> > >>>> > be a
>> > >>>> > >>> new command? like 'cordova platform pop ios' ?
>> > >>>> > >>>
>> > >>>> > >>> 4. we can add a flag to platform update ios --kill to do a
>> > >>>> destructive
>> > >>>> > >>> update for users who know that that is what they want.
>> > >>>> > >>>
>> > >>>> > >>> 5. [optional | stretch ] allow build/run of platform artifacts
>> > as
>> > >>>> > well, so
>> > >>>> > >>> developers can run commands like : 'cordova run ios@4.0.1'
>> > >>>> > >>>
>> > >>>> > >>> 6. the platform listed in config.xml would always be the
>> latest
>> > >>>> one,
>> > >>>> > >>> regardless of how many artifacts were still around.
>> > >>>> > >>>
>> > >>>> > >>> Thoughts? Issues? Comments?
>> > >>>> > >>>
>> > >>>> > >>>
>> > >>>> > >>>
>> > >>>> > >>>
>> > >>>> > >>>
>> > >>>> > >>>
>> > >>>> > >>>
>> > >>>> > >>>
>> > >>>> > >>>
>> > >>>> > >>>
>> > >>>> > >>> @purplecabbage
>> > >>>> > >>>
>> > >>>> >
>> > >>>>
>> >
>> https://na01.safelinks.protection.outlook.com/?url=risingj.com&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AYCfungKQfswLZClqFCBX2oacLlJixX8xOGAFiJjJcQ%3d
>> > >>>> > >>>
>> > >>>> > >>> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <
>> > >>>> dan@cellartracker.com>
>> > >>>> > wrote:
>> > >>>> > >>>
>> > >>>> > >>>> As a user of cordova (and list lurker), I thought I'd chime
>> in
>> > >>>> and say
>> > >>>> > >>>> Carlos hit on some very good points. In theory I like the
>> idea
>> > of
>> > >>>> > treating
>> > >>>> > >>>> platforms like build artifacts, but in reality -- at least
>> for
>> > my
>> > >>>> > current
>> > >>>> > >>>> usage -- things are far from that. Making this type of change
>> > >>>> will
>> > >>>> > make my
>> > >>>> > >>>> upgrades more challenging. I'm willing to live with that, but
>> > >>>> PLEASE
>> > >>>> > make
>> > >>>> > >>>> sure you do a backup (or tell the user to) "just in case"
>> > before
>> > >>>> > nuking
>> > >>>> > >>>> their directory.
>> > >>>> > >>>>
>> > >>>> > >>>> Right now, I find I do more native (non CLI) development on
>> iOS
>> > >>>> > compared
>> > >>>> > >>>> to other platforms. I'd have to do a full inventory of all of
>> > my
>> > >>>> > native
>> > >>>> > >>>> customizations, but as Carlos mentions it is a combination
>> of:
>> > >>>> > >>>>
>> > >>>> > >>>> - working around bugs/limitations in the tools
>> > >>>> > >>>> - additional AppDelegate customizations for native analytics
>> > >>>> > libraries and
>> > >>>> > >>>> error handling as our app is remotely hosted
>> > >>>> > >>>> - the addition of dependencies as cocoapods
>> > >>>> > >>>> - other build/plist customizations which are far simpler to
>> > >>>> modify
>> > >>>> > >>>> directly, e.g. adding an entitlements file to support
>> universal
>> > >>>> > links, or
>> > >>>> > >>>> adding ITSEncryptionExportComplianceCode to the plist to
>> > >>>> simplify app
>> > >>>> > >>>> submissions
>> > >>>> > >>>>
>> > >>>> > >>>> Anyway, please just keep in mind those of us who may be doing
>> > >>>> things
>> > >>>> > the
>> > >>>> > >>>> "old way" as you move forward here.
>> > >>>> > >>>>
>> > >>>> > >>>> Dan
>> > >>>> > >>>>
>> > >>>> > >>>> -----Original Message-----
>> > >>>> > >>>> From: Carlos Santana [mailto:csantana23@gmail.com]
>> > >>>> > >>>> Sent: Tuesday, March 08, 2016 3:16 PM
>> > >>>> > >>>> To: dev@cordova.apache.org
>> > >>>> > >>>> Subject: Re: [PROPOSAL] 'cordova platform update' alias for
>> rm,
>> > >>>> add in
>> > >>>> > >>>> cordova-ios
>> > >>>> > >>>>
>> > >>>> > >>>> I was never a fan of the "platform update" command since it
>> was
>> > >>>> not
>> > >>>> > fully
>> > >>>> > >>>> tested across the board.
>> > >>>> > >>>> like all the permutations possible to/from upgrade. meaning
>> > >>>> going for
>> > >>>> > very
>> > >>>> > >>>> old like 3.6 to 5.1
>> > >>>> > >>>>
>> > >>>> > >>>> If we do this I think it will break a lot of people that got
>> > >>>> used to
>> > >>>> > >>>> changing files inside platform/ios/ in terms of changing
>> XCode
>> > >>>> > settings in
>> > >>>> > >>>> pbxproj like:
>> > >>>> > >>>> - use story board to launch app to be able to support ipad
>> pro
>> > >>>> > >>>> - some initialization code in AppDelegate
>> > >>>> > >>>> - Any native code they added like NativeUI to mix web and
>> > native
>> > >>>> > >>>> - Changes to StoryBoard to adjust webview inside native view
>> > >>>> > >>>> - Build and Signing settings in project or target in XCode
>> > >>>> > >>>> - Installation of cocoapods
>> > >>>> > >>>> - Xcode Build phases scripts
>> > >>>> > >>>>
>> > >>>> > >>>> Meaning that they will need to restore or generate all this
>> > >>>> things
>> > >>>> > with
>> > >>>> > >>>> hooks or plugins.
>> > >>>> > >>>>
>> > >>>> > >>>> I know that Darryl Pogue and Tommy have projects where they
>> > can
>> > >>>> > >>>> successfully treat platfforms folder as 100% build artifact
>> > that
>> > >>>> they
>> > >>>> > can
>> > >>>> > >>>> throw away. But to get there is not super easy
>> > >>>> > >>>>
>> > >>>> > >>>> "platform update ios" has being scoped to only touch the
>> > >>>> CordovaLib
>> > >>>> > xcode
>> > >>>> > >>>> project, leaving the app xcode project not touched that's why
>> > >>>> it's
>> > >>>> > being
>> > >>>> > >>>> safe all along
>> > >>>> > >>>>
>> > >>>> > >>>> What was the root cause of the recent problems with 4.1.0 for
>> > >>>> update?
>> > >>>> > >>>>
>> > >>>> > >>>> Maybe we can restrict update command to major version,
>> meaning
>> > >>>> going
>> > >>>> > from
>> > >>>> > >>>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
>> > >>>> > >>>>
>> > >>>> > >>>> In the current release of the IBM MobileFirst, were we have a
>> > >>>> CLI to
>> > >>>> > wrap
>> > >>>> > >>>> cordova commands we had a "$ mfp cordova platform update"
>> > >>>> > >>>> We took a backup of the platform folder and create a zip
>> with a
>> > >>>> > timestamp
>> > >>>> > >>>> (like ios_1457477724404.zip)
>> > >>>> > >>>> We did this just in case the command was destructive and user
>> > >>>> didn't
>> > >>>> > lost
>> > >>>> > >>>> files just in case they didn't have all files
>> checked-in/backup
>> > >>>> > >>>>
>> > >>>> > >>>> So doing a backup would be good if we move forward with this
>> > >>>> > destructive
>> > >>>> > >>>> action of doing a platform remove
>> > >>>> > >>>>
>> > >>>> > >>>>
>> > >>>> > >>>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <
>> > >>>> byoungro.so@intel.com>
>> > >>>> > wrote:
>> > >>>> > >>>>
>> > >>>> > >>>> > I second that. +1
>> > >>>> > >>>> >
>> > >>>> > >>>> > Byoungro So
>> > >>>> > >>>> > SSG / DPD / Mobile Computing and Compilers
>> > >>>> > >>>> > Intel Corporation
>> > >>>> > >>>> >
>> > >>>> > >>>> > From: Anis KADRI <anis.kadri@gmail.com<mailto:
>> > >>>> anis.kadri@gmail.com
>> > >>>> > >>
>> > >>>> > >>>> > Reply-To: "dev@cordova.apache.org<mailto:
>> > >>>> dev@cordova.apache.org>" <
>> > >>>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>> > >>>> > >>>> > Date: Tuesday, March 8, 2016 at 2:34 PM
>> > >>>> > >>>> > To: "dev@cordova.apache.org<mailto:dev@cordova.apache.org
>> >"
>> > <
>> > >>>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>> > >>>> > >>>> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for
>> > >>>> rm, add
>> > >>>> > in
>> > >>>> > >>>> > cordova-ios
>> > >>>> > >>>> >
>> > >>>> > >>>> > I support this as well. Real updates never work. Better to
>> > >>>> > remove/add.
>> > >>>> > >>>> >
>> > >>>> > >>>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <
>> > >>>> stevengill97@gmail.com
>> > >>>> > >>>> > <ma...@gmail.com>> wrote:
>> > >>>> > >>>> >
>> > >>>> > >>>> > I would also like to see this happen. Would this cause
>> > >>>> problems if
>> > >>>> > we did
>> > >>>> > >>>> > this for other platforms?
>> > >>>> > >>>> >
>> > >>>> > >>>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <
>> shazron@gmail.com
>> > >>>> <mailto:
>> > >>>> > >>>> > shazron@gmail.com>> wrote:
>> > >>>> > >>>> >
>> > >>>> > >>>> > > See:
>> > >>>> > >>>> > >
>> > >>>> >
>> > >>>>
>> >
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
>> > >>>> > >>>> > >
>> > >>>> > >>>> > > Problem:
>> > >>>> > >>>> > > For cordova-ios, "cordova platform update" does its own
>> > >>>> thing,
>> > >>>> > which
>> > >>>> > >>>> > > causes problems.
>> > >>>> > >>>> > >
>> > >>>> > >>>> > > Proposal:
>> > >>>> > >>>> > > Change "cordova platform update ios@version" to be
>> > >>>> basically an
>> > >>>> > alias
>> > >>>> > >>>> > for:
>> > >>>> > >>>> > > "cordova platform rm ios"
>> > >>>> > >>>> > > "cordova platform add ios@version"
>> > >>>> > >>>> > >
>> > >>>> > >>>> > >
>> > >>>> >
>> > ---------------------------------------------------------------------
>> > >>>> > >>>> > > To unsubscribe, e-mail:
>> dev-unsubscribe@cordova.apache.org
>> > >>>> > <mailto:
>> > >>>> > >>>> > dev-unsubscribe@cordova.apache.org>
>> > >>>> > >>>> > > For additional commands, e-mail:
>> > dev-help@cordova.apache.org
>> > >>>> > <mailto:
>> > >>>> > >>>> > dev-help@cordova.apache.org>
>> > >>>> > >>>> > >
>> > >>>> > >>>> > >
>> > >>>> > >>>> >
>> > >>>> > >>>> >
>> > >>>> > >>>> >
>> > >>>> > >>>> >
>> > >>>> >
>> > ---------------------------------------------------------------------
>> > >>>> > >>>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > >>>> > >>>> > For additional commands, e-mail:
>> dev-help@cordova.apache.org
>> > >>>> > >>>> >
>> > >>>> > >>>>
>> > >>>> > >>>>
>> > >>>>
>> ---------------------------------------------------------------------
>> > >>>> > >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > >>>> > >>>> For additional commands, e-mail: dev-help@cordova.apache.org
>> > >>>> > >>>>
>> > >>>> > >
>> > >>>> >
>> > >---------------------------------------------------------------------
>> > >>>> > >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > >>>> > >For additional commands, e-mail: dev-help@cordova.apache.org
>> > >>>> > >
>> > >>>> >
>> > >>>> >
>> > >>>>
>> > >>>
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Carlos Santana <cs...@gmail.com>.
yep I agree Julio about adding more power to config.xml, that's basically
what Mike's hook those allow <config-file> tag in config.xml
On Wed, Mar 16, 2016 at 10:23 AM julio cesar sanchez <jc...@gmail.com>
wrote:
> I like Jesse's proposal
>
> for #3 I think we should use a new command, I like cordova *downgrade*
> platform
>
> As I usually read most cordova questions on stackoverflow, most people is
> editing and tellign others to edit the .plist manually and doing some other
> manual changes. I always point them to use hooks or plugins to do that, but
> as it's harder they don't want to do it.
>
> BTW, I think we should add a way to write on the AndroidManifest.xml and
> info.plist from the config.xml as phonegap build does, using the
> config-file tag. Right now it's possible to use the config-file tag on
> plugin.xml but not on config.xml
>
>
>
>
> 2016-03-16 14:54 GMT+01:00 Carlos Santana <cs...@gmail.com>:
>
> > Here is an example [1] of hooks created by ionic team member extending
> > config.xml to allow user to configure their native sdk settings allowing
> > have platforms as build artifacts.
> >
> > This could be a start at looking at some basic configuration settings via
> > hooks cordova provides or just in cordova tooling (i.e. platformAPI
> parser)
> >
> > [1]: https://github.com/mhartington/cordova-config-utils
> >
> >
> > On Tue, Mar 15, 2016 at 10:31 PM Carlos Santana <cs...@gmail.com>
> > wrote:
> >
> > > Scratch the "migrate cli command" idea. Now I think about it really
> messy
> > > and it will be another hackHooks.
> > >
> > > I think we concentrate to provide more capabilities thru config.xml and
> > > hooks for making migration more smooth.
> > >
> > > Like a running hooks on after_platform_update event and providing more
> > > information in the hook context argument with from to platform info
> > >
> > >
> > >
> > > On Tue, Mar 15, 2016 at 9:52 PM Carlos Santana <cs...@gmail.com>
> > > wrote:
> > >
> > >> By "I like the proposal and deleting all previous versions I don't see
> > as
> > >> an issue." I meant that I don't have an issue if we don't have this
> > feature
> > >> to clean old. I prefer not to have it
> > >>
> > >> On Tue, Mar 15, 2016 at 9:51 PM Carlos Santana <cs...@gmail.com>
> > >> wrote:
> > >>
> > >>> I like the proposal and deleting all previous versions I don't see as
> > an
> > >>> issue.
> > >>>
> > >>> I didn't get the part of using symlinks, I don't symlinks they bring
> a
> > >>> lot of problems to implement correctly I prefer we stick to real
> > directory
> > >>> and rename directories, user can choose to create symlinks on their
> > needs,
> > >>> we would just handle them.
> > >>>
> > >>> If end up doing a flag I prefer just deleting the one being replace,
> as
> > >>> --no-backup
> > >>> cordova platform update ios --no-backup (using nopt notation)
> > >>> will do the rename ios -> ios@4.0.1
> > >>> will do the add ios
> > >>> then only then if the add works and all plugins present get install
> and
> > >>> cli exist with none zero go and don't save the backup and delete the
> > folder
> > >>> that was rename to ios@4.0.1
> > >>>
> > >>> But I agree for now implement default to always do a backup, no flag
> > >>> (maybe experimental)
> > >>>
> > >>> User needs to be explicit on harmful actions, they can do platform rm
> > >>> ios@4.0.1 will simple delete /platforms/ios@4.0.1
> > >>> and he can do it for any platform current/active or old backups
> > >>>
> > >>> I'm OK about this proposal and we can start a new one that covers how
> > to
> > >>> help with migration. Since update becomes backup,
> > >>> We need to think how much we invest in migration, value of cordova is
> > on
> > >>> the runtime (core platform, and plugins)
> > >>>
> > >>> We can do start iterating with implementing enablement but specific
> > >>> migration tasks/actions are built on real experiences by the
> community.
> > >>> Meaning plugins/extensions that are plugable to handle migration,
> today
> > >>> peope do with hooks, I call those hackHooks :-), hooks that do hacks
> to
> > >>> make platforms build artifacts and be able to restore everything that
> > can't
> > >>> be restore with platform+plugins+config.xml
> > >>>
> > >>> So the flow I see if as the following:
> > >>>
> > >>> cordova platform update ios
> > >>> ....
> > >>> mv platforms/ios platforms/ios@4.0.1
> > >>> add platforms/ios
> > >>> ....
> > >>> cordova migrate ios ios@4.0.1
> > >>>
> > >>> This cli migrate command migrate helps user migrate things from 4.0.1
> > >>> (ios@4.0.1) to 4.1 (ios/current)
> > >>> migrate will run the actions/tasks/extensions added by the user, this
> > >>> actions/tasks/extensions (don't have a good name for migrations
> > "things")
> > >>> will be available on npm with keyword cordova:migrate
> > >>> For example there can be a command "migrate add
> > >>> cordova-migrate-entitlements" (this tasks migrate ios entitlements
> > from an
> > >>> old project to a new project)
> > >>> this tasks/extension will be added to list of steps to do to automate
> > >>> migration when cli command migrate runs
> > >>> Cordova project can provide the tooling and maybe a handful (or zero)
> > of
> > >>> well known tasks for migration, but not more, the rest will come from
> > the
> > >>> community/3rd party to maintain and publish, this will be a way for
> > people
> > >>> like Darryl and Tommy that have knowledge on migration and hooks they
> > can
> > >>> convert those to migration npm packages to share.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> On Mon, Mar 14, 2016 at 8:21 PM Jesse <pu...@gmail.com>
> wrote:
> > >>>
> > >>>> Yeah, the simple approach is probably the best!
> > >>>>
> > >>>> Move to strike --kill or any variation of it, and let developers
> > delete
> > >>>> what they want to. If it proves to be an issue, then we will
> address
> > >>>> it.
> > >>>>
> > >>>>
> > >>>> @purplecabbage
> > >>>> risingj.com
> > >>>>
> > >>>> On Mon, Mar 14, 2016 at 3:58 PM, Parashuram N <
> panarasi@microsoft.com
> > >
> > >>>> wrote:
> > >>>>
> > >>>> > Instead of adding an entire flag to remove previous versions, does
> > it
> > >>>> make
> > >>>> > sense to have cordova platform android@oldVersion. Alternatively,
> > >>>> users
> > >>>> > could simple use the terminal to delete older versions from the
> > >>>> command
> > >>>> > line inside the platform folders.
> > >>>> > If we have users asking for a way to “remove all older platforms”,
> > we
> > >>>> > could then introduce this flag.
> > >>>> >
> > >>>> > On 3/14/16, 2:07 PM, "Shazron" <sh...@gmail.com> wrote:
> > >>>> >
> > >>>> > >Note:
> > >>>> > >I prefer `--remove-previous-versions` to `--kill` so as to be
> > >>>> > >unambiguous and explicit.
> > >>>> > >
> > >>>> > >On Mon, Mar 14, 2016 at 2:01 PM, Shazron <sh...@gmail.com>
> > wrote:
> > >>>> > >> +1 I like it (esp reasons in #2)
> > >>>> > >>
> > >>>> > >> I agree that platform rm+add is not there yet, case in point
> all
> > >>>> the
> > >>>> > >> related issues in the "Issue Links" in this issue:
> > >>>> > >>
> > >>>> >
> > >>>>
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
> > >>>> > >>
> > >>>> > >> Some comments:
> > >>>> > >>
> > >>>> > >> `cordova platform ls` should list these previous versions as
> > well.
> > >>>> > >>
> > >>>> > >> `cordova platform add ios` should not delete these previous
> > >>>> versions?
> > >>>> > >>
> > >>>> > >> `cordova platform update ios --kill` kills *all* previous
> > versions,
> > >>>> > >> regardless of major version (clarification)
> > >>>> > >>
> > >>>> > >> `cordova platform rm ios` should just remove the current
> version
> > >>>> so it
> > >>>> > >> doesn't get confusing. If we have listing of the previous
> > versions
> > >>>> > >> above in `cordova platform ls`, you would have to explicitly
> do a
> > >>>> > >> `cordova platform rm ios@4.0.1` for example. However, this
> does
> > >>>> not
> > >>>> > >> solve for a way to remove *all* previous versions (we will have
> > to
> > >>>> > >> figure out a new command?)
> > >>>> > >>
> > >>>> > >>
> > >>>> > >> On Mon, Mar 14, 2016 at 1:29 PM, Jesse <
> purplecabbage@gmail.com>
> > >>>> wrote:
> > >>>> > >>> Considering all of the points previously mentioned, I would
> like
> > >>>> to
> > >>>> > make a
> > >>>> > >>> supplementary proposal.
> > >>>> > >>>
> > >>>> > >>> We seem to all agree that platform rm+add is ideal in a world
> > >>>> where we
> > >>>> > can
> > >>>> > >>> truly consider platforms as artifacts, but we are really not
> > >>>> there yet.
> > >>>> > >>> The zipped snapshot of the platform before the update that
> > Carlos
> > >>>> > mentions
> > >>>> > >>> is a good non-destructive way of allowing a developer the
> chance
> > >>>> to
> > >>>> > always
> > >>>> > >>> go back.
> > >>>> > >>> I would like to take this approach one step further and
> suggest:
> > >>>> > >>> (note: I am using 'ios' as the example platform, but this
> > >>>> applies to
> > >>>> > >>> any/all platforms )
> > >>>> > >>>
> > >>>> > >>> 1. when updating a project, we rename the previous
> > platforms/ios/
> > >>>> to
> > >>>> > >>> include the version it was, and leave it in the platforms
> > folder.
> > >>>> > >>> ex. platforms/ios/ -> platforms/ios@4.0.1/
> > >>>> > >>>
> > >>>> > >>> 2. platforms/ios would always contain the latest ios version
> > >>>> installed
> > >>>> > for
> > >>>> > >>> this project. This would allow most tooling to work unchanged,
> > and
> > >>>> > >>> sidesteps symlink issues on windows with things like
> ios-latest
> > ->
> > >>>> > ios@4.02
> > >>>> > >>>
> > >>>> > >>> 3. [optional or stretch goal] 'platform rm ios' could be used
> to
> > >>>> go
> > >>>> > back to
> > >>>> > >>> the previous 'current' version ( according to semver ) or
> should
> > >>>> this
> > >>>> > be a
> > >>>> > >>> new command? like 'cordova platform pop ios' ?
> > >>>> > >>>
> > >>>> > >>> 4. we can add a flag to platform update ios --kill to do a
> > >>>> destructive
> > >>>> > >>> update for users who know that that is what they want.
> > >>>> > >>>
> > >>>> > >>> 5. [optional | stretch ] allow build/run of platform artifacts
> > as
> > >>>> > well, so
> > >>>> > >>> developers can run commands like : 'cordova run ios@4.0.1'
> > >>>> > >>>
> > >>>> > >>> 6. the platform listed in config.xml would always be the
> latest
> > >>>> one,
> > >>>> > >>> regardless of how many artifacts were still around.
> > >>>> > >>>
> > >>>> > >>> Thoughts? Issues? Comments?
> > >>>> > >>>
> > >>>> > >>>
> > >>>> > >>>
> > >>>> > >>>
> > >>>> > >>>
> > >>>> > >>>
> > >>>> > >>>
> > >>>> > >>>
> > >>>> > >>>
> > >>>> > >>>
> > >>>> > >>> @purplecabbage
> > >>>> > >>>
> > >>>> >
> > >>>>
> >
> https://na01.safelinks.protection.outlook.com/?url=risingj.com&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AYCfungKQfswLZClqFCBX2oacLlJixX8xOGAFiJjJcQ%3d
> > >>>> > >>>
> > >>>> > >>> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <
> > >>>> dan@cellartracker.com>
> > >>>> > wrote:
> > >>>> > >>>
> > >>>> > >>>> As a user of cordova (and list lurker), I thought I'd chime
> in
> > >>>> and say
> > >>>> > >>>> Carlos hit on some very good points. In theory I like the
> idea
> > of
> > >>>> > treating
> > >>>> > >>>> platforms like build artifacts, but in reality -- at least
> for
> > my
> > >>>> > current
> > >>>> > >>>> usage -- things are far from that. Making this type of change
> > >>>> will
> > >>>> > make my
> > >>>> > >>>> upgrades more challenging. I'm willing to live with that, but
> > >>>> PLEASE
> > >>>> > make
> > >>>> > >>>> sure you do a backup (or tell the user to) "just in case"
> > before
> > >>>> > nuking
> > >>>> > >>>> their directory.
> > >>>> > >>>>
> > >>>> > >>>> Right now, I find I do more native (non CLI) development on
> iOS
> > >>>> > compared
> > >>>> > >>>> to other platforms. I'd have to do a full inventory of all of
> > my
> > >>>> > native
> > >>>> > >>>> customizations, but as Carlos mentions it is a combination
> of:
> > >>>> > >>>>
> > >>>> > >>>> - working around bugs/limitations in the tools
> > >>>> > >>>> - additional AppDelegate customizations for native analytics
> > >>>> > libraries and
> > >>>> > >>>> error handling as our app is remotely hosted
> > >>>> > >>>> - the addition of dependencies as cocoapods
> > >>>> > >>>> - other build/plist customizations which are far simpler to
> > >>>> modify
> > >>>> > >>>> directly, e.g. adding an entitlements file to support
> universal
> > >>>> > links, or
> > >>>> > >>>> adding ITSEncryptionExportComplianceCode to the plist to
> > >>>> simplify app
> > >>>> > >>>> submissions
> > >>>> > >>>>
> > >>>> > >>>> Anyway, please just keep in mind those of us who may be doing
> > >>>> things
> > >>>> > the
> > >>>> > >>>> "old way" as you move forward here.
> > >>>> > >>>>
> > >>>> > >>>> Dan
> > >>>> > >>>>
> > >>>> > >>>> -----Original Message-----
> > >>>> > >>>> From: Carlos Santana [mailto:csantana23@gmail.com]
> > >>>> > >>>> Sent: Tuesday, March 08, 2016 3:16 PM
> > >>>> > >>>> To: dev@cordova.apache.org
> > >>>> > >>>> Subject: Re: [PROPOSAL] 'cordova platform update' alias for
> rm,
> > >>>> add in
> > >>>> > >>>> cordova-ios
> > >>>> > >>>>
> > >>>> > >>>> I was never a fan of the "platform update" command since it
> was
> > >>>> not
> > >>>> > fully
> > >>>> > >>>> tested across the board.
> > >>>> > >>>> like all the permutations possible to/from upgrade. meaning
> > >>>> going for
> > >>>> > very
> > >>>> > >>>> old like 3.6 to 5.1
> > >>>> > >>>>
> > >>>> > >>>> If we do this I think it will break a lot of people that got
> > >>>> used to
> > >>>> > >>>> changing files inside platform/ios/ in terms of changing
> XCode
> > >>>> > settings in
> > >>>> > >>>> pbxproj like:
> > >>>> > >>>> - use story board to launch app to be able to support ipad
> pro
> > >>>> > >>>> - some initialization code in AppDelegate
> > >>>> > >>>> - Any native code they added like NativeUI to mix web and
> > native
> > >>>> > >>>> - Changes to StoryBoard to adjust webview inside native view
> > >>>> > >>>> - Build and Signing settings in project or target in XCode
> > >>>> > >>>> - Installation of cocoapods
> > >>>> > >>>> - Xcode Build phases scripts
> > >>>> > >>>>
> > >>>> > >>>> Meaning that they will need to restore or generate all this
> > >>>> things
> > >>>> > with
> > >>>> > >>>> hooks or plugins.
> > >>>> > >>>>
> > >>>> > >>>> I know that Darryl Pogue and Tommy have projects where they
> > can
> > >>>> > >>>> successfully treat platfforms folder as 100% build artifact
> > that
> > >>>> they
> > >>>> > can
> > >>>> > >>>> throw away. But to get there is not super easy
> > >>>> > >>>>
> > >>>> > >>>> "platform update ios" has being scoped to only touch the
> > >>>> CordovaLib
> > >>>> > xcode
> > >>>> > >>>> project, leaving the app xcode project not touched that's why
> > >>>> it's
> > >>>> > being
> > >>>> > >>>> safe all along
> > >>>> > >>>>
> > >>>> > >>>> What was the root cause of the recent problems with 4.1.0 for
> > >>>> update?
> > >>>> > >>>>
> > >>>> > >>>> Maybe we can restrict update command to major version,
> meaning
> > >>>> going
> > >>>> > from
> > >>>> > >>>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
> > >>>> > >>>>
> > >>>> > >>>> In the current release of the IBM MobileFirst, were we have a
> > >>>> CLI to
> > >>>> > wrap
> > >>>> > >>>> cordova commands we had a "$ mfp cordova platform update"
> > >>>> > >>>> We took a backup of the platform folder and create a zip
> with a
> > >>>> > timestamp
> > >>>> > >>>> (like ios_1457477724404.zip)
> > >>>> > >>>> We did this just in case the command was destructive and user
> > >>>> didn't
> > >>>> > lost
> > >>>> > >>>> files just in case they didn't have all files
> checked-in/backup
> > >>>> > >>>>
> > >>>> > >>>> So doing a backup would be good if we move forward with this
> > >>>> > destructive
> > >>>> > >>>> action of doing a platform remove
> > >>>> > >>>>
> > >>>> > >>>>
> > >>>> > >>>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <
> > >>>> byoungro.so@intel.com>
> > >>>> > wrote:
> > >>>> > >>>>
> > >>>> > >>>> > I second that. +1
> > >>>> > >>>> >
> > >>>> > >>>> > Byoungro So
> > >>>> > >>>> > SSG / DPD / Mobile Computing and Compilers
> > >>>> > >>>> > Intel Corporation
> > >>>> > >>>> >
> > >>>> > >>>> > From: Anis KADRI <anis.kadri@gmail.com<mailto:
> > >>>> anis.kadri@gmail.com
> > >>>> > >>
> > >>>> > >>>> > Reply-To: "dev@cordova.apache.org<mailto:
> > >>>> dev@cordova.apache.org>" <
> > >>>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> > >>>> > >>>> > Date: Tuesday, March 8, 2016 at 2:34 PM
> > >>>> > >>>> > To: "dev@cordova.apache.org<mailto:dev@cordova.apache.org
> >"
> > <
> > >>>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> > >>>> > >>>> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for
> > >>>> rm, add
> > >>>> > in
> > >>>> > >>>> > cordova-ios
> > >>>> > >>>> >
> > >>>> > >>>> > I support this as well. Real updates never work. Better to
> > >>>> > remove/add.
> > >>>> > >>>> >
> > >>>> > >>>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <
> > >>>> stevengill97@gmail.com
> > >>>> > >>>> > <ma...@gmail.com>> wrote:
> > >>>> > >>>> >
> > >>>> > >>>> > I would also like to see this happen. Would this cause
> > >>>> problems if
> > >>>> > we did
> > >>>> > >>>> > this for other platforms?
> > >>>> > >>>> >
> > >>>> > >>>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <
> shazron@gmail.com
> > >>>> <mailto:
> > >>>> > >>>> > shazron@gmail.com>> wrote:
> > >>>> > >>>> >
> > >>>> > >>>> > > See:
> > >>>> > >>>> > >
> > >>>> >
> > >>>>
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
> > >>>> > >>>> > >
> > >>>> > >>>> > > Problem:
> > >>>> > >>>> > > For cordova-ios, "cordova platform update" does its own
> > >>>> thing,
> > >>>> > which
> > >>>> > >>>> > > causes problems.
> > >>>> > >>>> > >
> > >>>> > >>>> > > Proposal:
> > >>>> > >>>> > > Change "cordova platform update ios@version" to be
> > >>>> basically an
> > >>>> > alias
> > >>>> > >>>> > for:
> > >>>> > >>>> > > "cordova platform rm ios"
> > >>>> > >>>> > > "cordova platform add ios@version"
> > >>>> > >>>> > >
> > >>>> > >>>> > >
> > >>>> >
> > ---------------------------------------------------------------------
> > >>>> > >>>> > > To unsubscribe, e-mail:
> dev-unsubscribe@cordova.apache.org
> > >>>> > <mailto:
> > >>>> > >>>> > dev-unsubscribe@cordova.apache.org>
> > >>>> > >>>> > > For additional commands, e-mail:
> > dev-help@cordova.apache.org
> > >>>> > <mailto:
> > >>>> > >>>> > dev-help@cordova.apache.org>
> > >>>> > >>>> > >
> > >>>> > >>>> > >
> > >>>> > >>>> >
> > >>>> > >>>> >
> > >>>> > >>>> >
> > >>>> > >>>> >
> > >>>> >
> > ---------------------------------------------------------------------
> > >>>> > >>>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >>>> > >>>> > For additional commands, e-mail:
> dev-help@cordova.apache.org
> > >>>> > >>>> >
> > >>>> > >>>>
> > >>>> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> > >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >>>> > >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>>> > >>>>
> > >>>> > >
> > >>>> >
> > >---------------------------------------------------------------------
> > >>>> > >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >>>> > >For additional commands, e-mail: dev-help@cordova.apache.org
> > >>>> > >
> > >>>> >
> > >>>> >
> > >>>>
> > >>>
> >
>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by julio cesar sanchez <jc...@gmail.com>.
I like Jesse's proposal
for #3 I think we should use a new command, I like cordova *downgrade*
platform
As I usually read most cordova questions on stackoverflow, most people is
editing and tellign others to edit the .plist manually and doing some other
manual changes. I always point them to use hooks or plugins to do that, but
as it's harder they don't want to do it.
BTW, I think we should add a way to write on the AndroidManifest.xml and
info.plist from the config.xml as phonegap build does, using the
config-file tag. Right now it's possible to use the config-file tag on
plugin.xml but not on config.xml
2016-03-16 14:54 GMT+01:00 Carlos Santana <cs...@gmail.com>:
> Here is an example [1] of hooks created by ionic team member extending
> config.xml to allow user to configure their native sdk settings allowing
> have platforms as build artifacts.
>
> This could be a start at looking at some basic configuration settings via
> hooks cordova provides or just in cordova tooling (i.e. platformAPI parser)
>
> [1]: https://github.com/mhartington/cordova-config-utils
>
>
> On Tue, Mar 15, 2016 at 10:31 PM Carlos Santana <cs...@gmail.com>
> wrote:
>
> > Scratch the "migrate cli command" idea. Now I think about it really messy
> > and it will be another hackHooks.
> >
> > I think we concentrate to provide more capabilities thru config.xml and
> > hooks for making migration more smooth.
> >
> > Like a running hooks on after_platform_update event and providing more
> > information in the hook context argument with from to platform info
> >
> >
> >
> > On Tue, Mar 15, 2016 at 9:52 PM Carlos Santana <cs...@gmail.com>
> > wrote:
> >
> >> By "I like the proposal and deleting all previous versions I don't see
> as
> >> an issue." I meant that I don't have an issue if we don't have this
> feature
> >> to clean old. I prefer not to have it
> >>
> >> On Tue, Mar 15, 2016 at 9:51 PM Carlos Santana <cs...@gmail.com>
> >> wrote:
> >>
> >>> I like the proposal and deleting all previous versions I don't see as
> an
> >>> issue.
> >>>
> >>> I didn't get the part of using symlinks, I don't symlinks they bring a
> >>> lot of problems to implement correctly I prefer we stick to real
> directory
> >>> and rename directories, user can choose to create symlinks on their
> needs,
> >>> we would just handle them.
> >>>
> >>> If end up doing a flag I prefer just deleting the one being replace, as
> >>> --no-backup
> >>> cordova platform update ios --no-backup (using nopt notation)
> >>> will do the rename ios -> ios@4.0.1
> >>> will do the add ios
> >>> then only then if the add works and all plugins present get install and
> >>> cli exist with none zero go and don't save the backup and delete the
> folder
> >>> that was rename to ios@4.0.1
> >>>
> >>> But I agree for now implement default to always do a backup, no flag
> >>> (maybe experimental)
> >>>
> >>> User needs to be explicit on harmful actions, they can do platform rm
> >>> ios@4.0.1 will simple delete /platforms/ios@4.0.1
> >>> and he can do it for any platform current/active or old backups
> >>>
> >>> I'm OK about this proposal and we can start a new one that covers how
> to
> >>> help with migration. Since update becomes backup,
> >>> We need to think how much we invest in migration, value of cordova is
> on
> >>> the runtime (core platform, and plugins)
> >>>
> >>> We can do start iterating with implementing enablement but specific
> >>> migration tasks/actions are built on real experiences by the community.
> >>> Meaning plugins/extensions that are plugable to handle migration, today
> >>> peope do with hooks, I call those hackHooks :-), hooks that do hacks to
> >>> make platforms build artifacts and be able to restore everything that
> can't
> >>> be restore with platform+plugins+config.xml
> >>>
> >>> So the flow I see if as the following:
> >>>
> >>> cordova platform update ios
> >>> ....
> >>> mv platforms/ios platforms/ios@4.0.1
> >>> add platforms/ios
> >>> ....
> >>> cordova migrate ios ios@4.0.1
> >>>
> >>> This cli migrate command migrate helps user migrate things from 4.0.1
> >>> (ios@4.0.1) to 4.1 (ios/current)
> >>> migrate will run the actions/tasks/extensions added by the user, this
> >>> actions/tasks/extensions (don't have a good name for migrations
> "things")
> >>> will be available on npm with keyword cordova:migrate
> >>> For example there can be a command "migrate add
> >>> cordova-migrate-entitlements" (this tasks migrate ios entitlements
> from an
> >>> old project to a new project)
> >>> this tasks/extension will be added to list of steps to do to automate
> >>> migration when cli command migrate runs
> >>> Cordova project can provide the tooling and maybe a handful (or zero)
> of
> >>> well known tasks for migration, but not more, the rest will come from
> the
> >>> community/3rd party to maintain and publish, this will be a way for
> people
> >>> like Darryl and Tommy that have knowledge on migration and hooks they
> can
> >>> convert those to migration npm packages to share.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Mon, Mar 14, 2016 at 8:21 PM Jesse <pu...@gmail.com> wrote:
> >>>
> >>>> Yeah, the simple approach is probably the best!
> >>>>
> >>>> Move to strike --kill or any variation of it, and let developers
> delete
> >>>> what they want to. If it proves to be an issue, then we will address
> >>>> it.
> >>>>
> >>>>
> >>>> @purplecabbage
> >>>> risingj.com
> >>>>
> >>>> On Mon, Mar 14, 2016 at 3:58 PM, Parashuram N <panarasi@microsoft.com
> >
> >>>> wrote:
> >>>>
> >>>> > Instead of adding an entire flag to remove previous versions, does
> it
> >>>> make
> >>>> > sense to have cordova platform android@oldVersion. Alternatively,
> >>>> users
> >>>> > could simple use the terminal to delete older versions from the
> >>>> command
> >>>> > line inside the platform folders.
> >>>> > If we have users asking for a way to “remove all older platforms”,
> we
> >>>> > could then introduce this flag.
> >>>> >
> >>>> > On 3/14/16, 2:07 PM, "Shazron" <sh...@gmail.com> wrote:
> >>>> >
> >>>> > >Note:
> >>>> > >I prefer `--remove-previous-versions` to `--kill` so as to be
> >>>> > >unambiguous and explicit.
> >>>> > >
> >>>> > >On Mon, Mar 14, 2016 at 2:01 PM, Shazron <sh...@gmail.com>
> wrote:
> >>>> > >> +1 I like it (esp reasons in #2)
> >>>> > >>
> >>>> > >> I agree that platform rm+add is not there yet, case in point all
> >>>> the
> >>>> > >> related issues in the "Issue Links" in this issue:
> >>>> > >>
> >>>> >
> >>>>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
> >>>> > >>
> >>>> > >> Some comments:
> >>>> > >>
> >>>> > >> `cordova platform ls` should list these previous versions as
> well.
> >>>> > >>
> >>>> > >> `cordova platform add ios` should not delete these previous
> >>>> versions?
> >>>> > >>
> >>>> > >> `cordova platform update ios --kill` kills *all* previous
> versions,
> >>>> > >> regardless of major version (clarification)
> >>>> > >>
> >>>> > >> `cordova platform rm ios` should just remove the current version
> >>>> so it
> >>>> > >> doesn't get confusing. If we have listing of the previous
> versions
> >>>> > >> above in `cordova platform ls`, you would have to explicitly do a
> >>>> > >> `cordova platform rm ios@4.0.1` for example. However, this does
> >>>> not
> >>>> > >> solve for a way to remove *all* previous versions (we will have
> to
> >>>> > >> figure out a new command?)
> >>>> > >>
> >>>> > >>
> >>>> > >> On Mon, Mar 14, 2016 at 1:29 PM, Jesse <pu...@gmail.com>
> >>>> wrote:
> >>>> > >>> Considering all of the points previously mentioned, I would like
> >>>> to
> >>>> > make a
> >>>> > >>> supplementary proposal.
> >>>> > >>>
> >>>> > >>> We seem to all agree that platform rm+add is ideal in a world
> >>>> where we
> >>>> > can
> >>>> > >>> truly consider platforms as artifacts, but we are really not
> >>>> there yet.
> >>>> > >>> The zipped snapshot of the platform before the update that
> Carlos
> >>>> > mentions
> >>>> > >>> is a good non-destructive way of allowing a developer the chance
> >>>> to
> >>>> > always
> >>>> > >>> go back.
> >>>> > >>> I would like to take this approach one step further and suggest:
> >>>> > >>> (note: I am using 'ios' as the example platform, but this
> >>>> applies to
> >>>> > >>> any/all platforms )
> >>>> > >>>
> >>>> > >>> 1. when updating a project, we rename the previous
> platforms/ios/
> >>>> to
> >>>> > >>> include the version it was, and leave it in the platforms
> folder.
> >>>> > >>> ex. platforms/ios/ -> platforms/ios@4.0.1/
> >>>> > >>>
> >>>> > >>> 2. platforms/ios would always contain the latest ios version
> >>>> installed
> >>>> > for
> >>>> > >>> this project. This would allow most tooling to work unchanged,
> and
> >>>> > >>> sidesteps symlink issues on windows with things like ios-latest
> ->
> >>>> > ios@4.02
> >>>> > >>>
> >>>> > >>> 3. [optional or stretch goal] 'platform rm ios' could be used to
> >>>> go
> >>>> > back to
> >>>> > >>> the previous 'current' version ( according to semver ) or should
> >>>> this
> >>>> > be a
> >>>> > >>> new command? like 'cordova platform pop ios' ?
> >>>> > >>>
> >>>> > >>> 4. we can add a flag to platform update ios --kill to do a
> >>>> destructive
> >>>> > >>> update for users who know that that is what they want.
> >>>> > >>>
> >>>> > >>> 5. [optional | stretch ] allow build/run of platform artifacts
> as
> >>>> > well, so
> >>>> > >>> developers can run commands like : 'cordova run ios@4.0.1'
> >>>> > >>>
> >>>> > >>> 6. the platform listed in config.xml would always be the latest
> >>>> one,
> >>>> > >>> regardless of how many artifacts were still around.
> >>>> > >>>
> >>>> > >>> Thoughts? Issues? Comments?
> >>>> > >>>
> >>>> > >>>
> >>>> > >>>
> >>>> > >>>
> >>>> > >>>
> >>>> > >>>
> >>>> > >>>
> >>>> > >>>
> >>>> > >>>
> >>>> > >>>
> >>>> > >>> @purplecabbage
> >>>> > >>>
> >>>> >
> >>>>
> https://na01.safelinks.protection.outlook.com/?url=risingj.com&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AYCfungKQfswLZClqFCBX2oacLlJixX8xOGAFiJjJcQ%3d
> >>>> > >>>
> >>>> > >>> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <
> >>>> dan@cellartracker.com>
> >>>> > wrote:
> >>>> > >>>
> >>>> > >>>> As a user of cordova (and list lurker), I thought I'd chime in
> >>>> and say
> >>>> > >>>> Carlos hit on some very good points. In theory I like the idea
> of
> >>>> > treating
> >>>> > >>>> platforms like build artifacts, but in reality -- at least for
> my
> >>>> > current
> >>>> > >>>> usage -- things are far from that. Making this type of change
> >>>> will
> >>>> > make my
> >>>> > >>>> upgrades more challenging. I'm willing to live with that, but
> >>>> PLEASE
> >>>> > make
> >>>> > >>>> sure you do a backup (or tell the user to) "just in case"
> before
> >>>> > nuking
> >>>> > >>>> their directory.
> >>>> > >>>>
> >>>> > >>>> Right now, I find I do more native (non CLI) development on iOS
> >>>> > compared
> >>>> > >>>> to other platforms. I'd have to do a full inventory of all of
> my
> >>>> > native
> >>>> > >>>> customizations, but as Carlos mentions it is a combination of:
> >>>> > >>>>
> >>>> > >>>> - working around bugs/limitations in the tools
> >>>> > >>>> - additional AppDelegate customizations for native analytics
> >>>> > libraries and
> >>>> > >>>> error handling as our app is remotely hosted
> >>>> > >>>> - the addition of dependencies as cocoapods
> >>>> > >>>> - other build/plist customizations which are far simpler to
> >>>> modify
> >>>> > >>>> directly, e.g. adding an entitlements file to support universal
> >>>> > links, or
> >>>> > >>>> adding ITSEncryptionExportComplianceCode to the plist to
> >>>> simplify app
> >>>> > >>>> submissions
> >>>> > >>>>
> >>>> > >>>> Anyway, please just keep in mind those of us who may be doing
> >>>> things
> >>>> > the
> >>>> > >>>> "old way" as you move forward here.
> >>>> > >>>>
> >>>> > >>>> Dan
> >>>> > >>>>
> >>>> > >>>> -----Original Message-----
> >>>> > >>>> From: Carlos Santana [mailto:csantana23@gmail.com]
> >>>> > >>>> Sent: Tuesday, March 08, 2016 3:16 PM
> >>>> > >>>> To: dev@cordova.apache.org
> >>>> > >>>> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm,
> >>>> add in
> >>>> > >>>> cordova-ios
> >>>> > >>>>
> >>>> > >>>> I was never a fan of the "platform update" command since it was
> >>>> not
> >>>> > fully
> >>>> > >>>> tested across the board.
> >>>> > >>>> like all the permutations possible to/from upgrade. meaning
> >>>> going for
> >>>> > very
> >>>> > >>>> old like 3.6 to 5.1
> >>>> > >>>>
> >>>> > >>>> If we do this I think it will break a lot of people that got
> >>>> used to
> >>>> > >>>> changing files inside platform/ios/ in terms of changing XCode
> >>>> > settings in
> >>>> > >>>> pbxproj like:
> >>>> > >>>> - use story board to launch app to be able to support ipad pro
> >>>> > >>>> - some initialization code in AppDelegate
> >>>> > >>>> - Any native code they added like NativeUI to mix web and
> native
> >>>> > >>>> - Changes to StoryBoard to adjust webview inside native view
> >>>> > >>>> - Build and Signing settings in project or target in XCode
> >>>> > >>>> - Installation of cocoapods
> >>>> > >>>> - Xcode Build phases scripts
> >>>> > >>>>
> >>>> > >>>> Meaning that they will need to restore or generate all this
> >>>> things
> >>>> > with
> >>>> > >>>> hooks or plugins.
> >>>> > >>>>
> >>>> > >>>> I know that Darryl Pogue and Tommy have projects where they
> can
> >>>> > >>>> successfully treat platfforms folder as 100% build artifact
> that
> >>>> they
> >>>> > can
> >>>> > >>>> throw away. But to get there is not super easy
> >>>> > >>>>
> >>>> > >>>> "platform update ios" has being scoped to only touch the
> >>>> CordovaLib
> >>>> > xcode
> >>>> > >>>> project, leaving the app xcode project not touched that's why
> >>>> it's
> >>>> > being
> >>>> > >>>> safe all along
> >>>> > >>>>
> >>>> > >>>> What was the root cause of the recent problems with 4.1.0 for
> >>>> update?
> >>>> > >>>>
> >>>> > >>>> Maybe we can restrict update command to major version, meaning
> >>>> going
> >>>> > from
> >>>> > >>>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
> >>>> > >>>>
> >>>> > >>>> In the current release of the IBM MobileFirst, were we have a
> >>>> CLI to
> >>>> > wrap
> >>>> > >>>> cordova commands we had a "$ mfp cordova platform update"
> >>>> > >>>> We took a backup of the platform folder and create a zip with a
> >>>> > timestamp
> >>>> > >>>> (like ios_1457477724404.zip)
> >>>> > >>>> We did this just in case the command was destructive and user
> >>>> didn't
> >>>> > lost
> >>>> > >>>> files just in case they didn't have all files checked-in/backup
> >>>> > >>>>
> >>>> > >>>> So doing a backup would be good if we move forward with this
> >>>> > destructive
> >>>> > >>>> action of doing a platform remove
> >>>> > >>>>
> >>>> > >>>>
> >>>> > >>>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <
> >>>> byoungro.so@intel.com>
> >>>> > wrote:
> >>>> > >>>>
> >>>> > >>>> > I second that. +1
> >>>> > >>>> >
> >>>> > >>>> > Byoungro So
> >>>> > >>>> > SSG / DPD / Mobile Computing and Compilers
> >>>> > >>>> > Intel Corporation
> >>>> > >>>> >
> >>>> > >>>> > From: Anis KADRI <anis.kadri@gmail.com<mailto:
> >>>> anis.kadri@gmail.com
> >>>> > >>
> >>>> > >>>> > Reply-To: "dev@cordova.apache.org<mailto:
> >>>> dev@cordova.apache.org>" <
> >>>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> >>>> > >>>> > Date: Tuesday, March 8, 2016 at 2:34 PM
> >>>> > >>>> > To: "dev@cordova.apache.org<ma...@cordova.apache.org>"
> <
> >>>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> >>>> > >>>> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for
> >>>> rm, add
> >>>> > in
> >>>> > >>>> > cordova-ios
> >>>> > >>>> >
> >>>> > >>>> > I support this as well. Real updates never work. Better to
> >>>> > remove/add.
> >>>> > >>>> >
> >>>> > >>>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <
> >>>> stevengill97@gmail.com
> >>>> > >>>> > <ma...@gmail.com>> wrote:
> >>>> > >>>> >
> >>>> > >>>> > I would also like to see this happen. Would this cause
> >>>> problems if
> >>>> > we did
> >>>> > >>>> > this for other platforms?
> >>>> > >>>> >
> >>>> > >>>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com
> >>>> <mailto:
> >>>> > >>>> > shazron@gmail.com>> wrote:
> >>>> > >>>> >
> >>>> > >>>> > > See:
> >>>> > >>>> > >
> >>>> >
> >>>>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
> >>>> > >>>> > >
> >>>> > >>>> > > Problem:
> >>>> > >>>> > > For cordova-ios, "cordova platform update" does its own
> >>>> thing,
> >>>> > which
> >>>> > >>>> > > causes problems.
> >>>> > >>>> > >
> >>>> > >>>> > > Proposal:
> >>>> > >>>> > > Change "cordova platform update ios@version" to be
> >>>> basically an
> >>>> > alias
> >>>> > >>>> > for:
> >>>> > >>>> > > "cordova platform rm ios"
> >>>> > >>>> > > "cordova platform add ios@version"
> >>>> > >>>> > >
> >>>> > >>>> > >
> >>>> >
> ---------------------------------------------------------------------
> >>>> > >>>> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>> > <mailto:
> >>>> > >>>> > dev-unsubscribe@cordova.apache.org>
> >>>> > >>>> > > For additional commands, e-mail:
> dev-help@cordova.apache.org
> >>>> > <mailto:
> >>>> > >>>> > dev-help@cordova.apache.org>
> >>>> > >>>> > >
> >>>> > >>>> > >
> >>>> > >>>> >
> >>>> > >>>> >
> >>>> > >>>> >
> >>>> > >>>> >
> >>>> >
> ---------------------------------------------------------------------
> >>>> > >>>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>> > >>>> > For additional commands, e-mail: dev-help@cordova.apache.org
> >>>> > >>>> >
> >>>> > >>>>
> >>>> > >>>>
> >>>> ---------------------------------------------------------------------
> >>>> > >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>> > >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>> > >>>>
> >>>> > >
> >>>> >
> >---------------------------------------------------------------------
> >>>> > >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>> > >For additional commands, e-mail: dev-help@cordova.apache.org
> >>>> > >
> >>>> >
> >>>> >
> >>>>
> >>>
>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Carlos Santana <cs...@gmail.com>.
Here is an example [1] of hooks created by ionic team member extending
config.xml to allow user to configure their native sdk settings allowing
have platforms as build artifacts.
This could be a start at looking at some basic configuration settings via
hooks cordova provides or just in cordova tooling (i.e. platformAPI parser)
[1]: https://github.com/mhartington/cordova-config-utils
On Tue, Mar 15, 2016 at 10:31 PM Carlos Santana <cs...@gmail.com>
wrote:
> Scratch the "migrate cli command" idea. Now I think about it really messy
> and it will be another hackHooks.
>
> I think we concentrate to provide more capabilities thru config.xml and
> hooks for making migration more smooth.
>
> Like a running hooks on after_platform_update event and providing more
> information in the hook context argument with from to platform info
>
>
>
> On Tue, Mar 15, 2016 at 9:52 PM Carlos Santana <cs...@gmail.com>
> wrote:
>
>> By "I like the proposal and deleting all previous versions I don't see as
>> an issue." I meant that I don't have an issue if we don't have this feature
>> to clean old. I prefer not to have it
>>
>> On Tue, Mar 15, 2016 at 9:51 PM Carlos Santana <cs...@gmail.com>
>> wrote:
>>
>>> I like the proposal and deleting all previous versions I don't see as an
>>> issue.
>>>
>>> I didn't get the part of using symlinks, I don't symlinks they bring a
>>> lot of problems to implement correctly I prefer we stick to real directory
>>> and rename directories, user can choose to create symlinks on their needs,
>>> we would just handle them.
>>>
>>> If end up doing a flag I prefer just deleting the one being replace, as
>>> --no-backup
>>> cordova platform update ios --no-backup (using nopt notation)
>>> will do the rename ios -> ios@4.0.1
>>> will do the add ios
>>> then only then if the add works and all plugins present get install and
>>> cli exist with none zero go and don't save the backup and delete the folder
>>> that was rename to ios@4.0.1
>>>
>>> But I agree for now implement default to always do a backup, no flag
>>> (maybe experimental)
>>>
>>> User needs to be explicit on harmful actions, they can do platform rm
>>> ios@4.0.1 will simple delete /platforms/ios@4.0.1
>>> and he can do it for any platform current/active or old backups
>>>
>>> I'm OK about this proposal and we can start a new one that covers how to
>>> help with migration. Since update becomes backup,
>>> We need to think how much we invest in migration, value of cordova is on
>>> the runtime (core platform, and plugins)
>>>
>>> We can do start iterating with implementing enablement but specific
>>> migration tasks/actions are built on real experiences by the community.
>>> Meaning plugins/extensions that are plugable to handle migration, today
>>> peope do with hooks, I call those hackHooks :-), hooks that do hacks to
>>> make platforms build artifacts and be able to restore everything that can't
>>> be restore with platform+plugins+config.xml
>>>
>>> So the flow I see if as the following:
>>>
>>> cordova platform update ios
>>> ....
>>> mv platforms/ios platforms/ios@4.0.1
>>> add platforms/ios
>>> ....
>>> cordova migrate ios ios@4.0.1
>>>
>>> This cli migrate command migrate helps user migrate things from 4.0.1
>>> (ios@4.0.1) to 4.1 (ios/current)
>>> migrate will run the actions/tasks/extensions added by the user, this
>>> actions/tasks/extensions (don't have a good name for migrations "things")
>>> will be available on npm with keyword cordova:migrate
>>> For example there can be a command "migrate add
>>> cordova-migrate-entitlements" (this tasks migrate ios entitlements from an
>>> old project to a new project)
>>> this tasks/extension will be added to list of steps to do to automate
>>> migration when cli command migrate runs
>>> Cordova project can provide the tooling and maybe a handful (or zero) of
>>> well known tasks for migration, but not more, the rest will come from the
>>> community/3rd party to maintain and publish, this will be a way for people
>>> like Darryl and Tommy that have knowledge on migration and hooks they can
>>> convert those to migration npm packages to share.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Mar 14, 2016 at 8:21 PM Jesse <pu...@gmail.com> wrote:
>>>
>>>> Yeah, the simple approach is probably the best!
>>>>
>>>> Move to strike --kill or any variation of it, and let developers delete
>>>> what they want to. If it proves to be an issue, then we will address
>>>> it.
>>>>
>>>>
>>>> @purplecabbage
>>>> risingj.com
>>>>
>>>> On Mon, Mar 14, 2016 at 3:58 PM, Parashuram N <pa...@microsoft.com>
>>>> wrote:
>>>>
>>>> > Instead of adding an entire flag to remove previous versions, does it
>>>> make
>>>> > sense to have cordova platform android@oldVersion. Alternatively,
>>>> users
>>>> > could simple use the terminal to delete older versions from the
>>>> command
>>>> > line inside the platform folders.
>>>> > If we have users asking for a way to “remove all older platforms”, we
>>>> > could then introduce this flag.
>>>> >
>>>> > On 3/14/16, 2:07 PM, "Shazron" <sh...@gmail.com> wrote:
>>>> >
>>>> > >Note:
>>>> > >I prefer `--remove-previous-versions` to `--kill` so as to be
>>>> > >unambiguous and explicit.
>>>> > >
>>>> > >On Mon, Mar 14, 2016 at 2:01 PM, Shazron <sh...@gmail.com> wrote:
>>>> > >> +1 I like it (esp reasons in #2)
>>>> > >>
>>>> > >> I agree that platform rm+add is not there yet, case in point all
>>>> the
>>>> > >> related issues in the "Issue Links" in this issue:
>>>> > >>
>>>> >
>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
>>>> > >>
>>>> > >> Some comments:
>>>> > >>
>>>> > >> `cordova platform ls` should list these previous versions as well.
>>>> > >>
>>>> > >> `cordova platform add ios` should not delete these previous
>>>> versions?
>>>> > >>
>>>> > >> `cordova platform update ios --kill` kills *all* previous versions,
>>>> > >> regardless of major version (clarification)
>>>> > >>
>>>> > >> `cordova platform rm ios` should just remove the current version
>>>> so it
>>>> > >> doesn't get confusing. If we have listing of the previous versions
>>>> > >> above in `cordova platform ls`, you would have to explicitly do a
>>>> > >> `cordova platform rm ios@4.0.1` for example. However, this does
>>>> not
>>>> > >> solve for a way to remove *all* previous versions (we will have to
>>>> > >> figure out a new command?)
>>>> > >>
>>>> > >>
>>>> > >> On Mon, Mar 14, 2016 at 1:29 PM, Jesse <pu...@gmail.com>
>>>> wrote:
>>>> > >>> Considering all of the points previously mentioned, I would like
>>>> to
>>>> > make a
>>>> > >>> supplementary proposal.
>>>> > >>>
>>>> > >>> We seem to all agree that platform rm+add is ideal in a world
>>>> where we
>>>> > can
>>>> > >>> truly consider platforms as artifacts, but we are really not
>>>> there yet.
>>>> > >>> The zipped snapshot of the platform before the update that Carlos
>>>> > mentions
>>>> > >>> is a good non-destructive way of allowing a developer the chance
>>>> to
>>>> > always
>>>> > >>> go back.
>>>> > >>> I would like to take this approach one step further and suggest:
>>>> > >>> (note: I am using 'ios' as the example platform, but this
>>>> applies to
>>>> > >>> any/all platforms )
>>>> > >>>
>>>> > >>> 1. when updating a project, we rename the previous platforms/ios/
>>>> to
>>>> > >>> include the version it was, and leave it in the platforms folder.
>>>> > >>> ex. platforms/ios/ -> platforms/ios@4.0.1/
>>>> > >>>
>>>> > >>> 2. platforms/ios would always contain the latest ios version
>>>> installed
>>>> > for
>>>> > >>> this project. This would allow most tooling to work unchanged, and
>>>> > >>> sidesteps symlink issues on windows with things like ios-latest ->
>>>> > ios@4.02
>>>> > >>>
>>>> > >>> 3. [optional or stretch goal] 'platform rm ios' could be used to
>>>> go
>>>> > back to
>>>> > >>> the previous 'current' version ( according to semver ) or should
>>>> this
>>>> > be a
>>>> > >>> new command? like 'cordova platform pop ios' ?
>>>> > >>>
>>>> > >>> 4. we can add a flag to platform update ios --kill to do a
>>>> destructive
>>>> > >>> update for users who know that that is what they want.
>>>> > >>>
>>>> > >>> 5. [optional | stretch ] allow build/run of platform artifacts as
>>>> > well, so
>>>> > >>> developers can run commands like : 'cordova run ios@4.0.1'
>>>> > >>>
>>>> > >>> 6. the platform listed in config.xml would always be the latest
>>>> one,
>>>> > >>> regardless of how many artifacts were still around.
>>>> > >>>
>>>> > >>> Thoughts? Issues? Comments?
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>>
>>>> > >>> @purplecabbage
>>>> > >>>
>>>> >
>>>> https://na01.safelinks.protection.outlook.com/?url=risingj.com&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AYCfungKQfswLZClqFCBX2oacLlJixX8xOGAFiJjJcQ%3d
>>>> > >>>
>>>> > >>> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <
>>>> dan@cellartracker.com>
>>>> > wrote:
>>>> > >>>
>>>> > >>>> As a user of cordova (and list lurker), I thought I'd chime in
>>>> and say
>>>> > >>>> Carlos hit on some very good points. In theory I like the idea of
>>>> > treating
>>>> > >>>> platforms like build artifacts, but in reality -- at least for my
>>>> > current
>>>> > >>>> usage -- things are far from that. Making this type of change
>>>> will
>>>> > make my
>>>> > >>>> upgrades more challenging. I'm willing to live with that, but
>>>> PLEASE
>>>> > make
>>>> > >>>> sure you do a backup (or tell the user to) "just in case" before
>>>> > nuking
>>>> > >>>> their directory.
>>>> > >>>>
>>>> > >>>> Right now, I find I do more native (non CLI) development on iOS
>>>> > compared
>>>> > >>>> to other platforms. I'd have to do a full inventory of all of my
>>>> > native
>>>> > >>>> customizations, but as Carlos mentions it is a combination of:
>>>> > >>>>
>>>> > >>>> - working around bugs/limitations in the tools
>>>> > >>>> - additional AppDelegate customizations for native analytics
>>>> > libraries and
>>>> > >>>> error handling as our app is remotely hosted
>>>> > >>>> - the addition of dependencies as cocoapods
>>>> > >>>> - other build/plist customizations which are far simpler to
>>>> modify
>>>> > >>>> directly, e.g. adding an entitlements file to support universal
>>>> > links, or
>>>> > >>>> adding ITSEncryptionExportComplianceCode to the plist to
>>>> simplify app
>>>> > >>>> submissions
>>>> > >>>>
>>>> > >>>> Anyway, please just keep in mind those of us who may be doing
>>>> things
>>>> > the
>>>> > >>>> "old way" as you move forward here.
>>>> > >>>>
>>>> > >>>> Dan
>>>> > >>>>
>>>> > >>>> -----Original Message-----
>>>> > >>>> From: Carlos Santana [mailto:csantana23@gmail.com]
>>>> > >>>> Sent: Tuesday, March 08, 2016 3:16 PM
>>>> > >>>> To: dev@cordova.apache.org
>>>> > >>>> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm,
>>>> add in
>>>> > >>>> cordova-ios
>>>> > >>>>
>>>> > >>>> I was never a fan of the "platform update" command since it was
>>>> not
>>>> > fully
>>>> > >>>> tested across the board.
>>>> > >>>> like all the permutations possible to/from upgrade. meaning
>>>> going for
>>>> > very
>>>> > >>>> old like 3.6 to 5.1
>>>> > >>>>
>>>> > >>>> If we do this I think it will break a lot of people that got
>>>> used to
>>>> > >>>> changing files inside platform/ios/ in terms of changing XCode
>>>> > settings in
>>>> > >>>> pbxproj like:
>>>> > >>>> - use story board to launch app to be able to support ipad pro
>>>> > >>>> - some initialization code in AppDelegate
>>>> > >>>> - Any native code they added like NativeUI to mix web and native
>>>> > >>>> - Changes to StoryBoard to adjust webview inside native view
>>>> > >>>> - Build and Signing settings in project or target in XCode
>>>> > >>>> - Installation of cocoapods
>>>> > >>>> - Xcode Build phases scripts
>>>> > >>>>
>>>> > >>>> Meaning that they will need to restore or generate all this
>>>> things
>>>> > with
>>>> > >>>> hooks or plugins.
>>>> > >>>>
>>>> > >>>> I know that Darryl Pogue and Tommy have projects where they can
>>>> > >>>> successfully treat platfforms folder as 100% build artifact that
>>>> they
>>>> > can
>>>> > >>>> throw away. But to get there is not super easy
>>>> > >>>>
>>>> > >>>> "platform update ios" has being scoped to only touch the
>>>> CordovaLib
>>>> > xcode
>>>> > >>>> project, leaving the app xcode project not touched that's why
>>>> it's
>>>> > being
>>>> > >>>> safe all along
>>>> > >>>>
>>>> > >>>> What was the root cause of the recent problems with 4.1.0 for
>>>> update?
>>>> > >>>>
>>>> > >>>> Maybe we can restrict update command to major version, meaning
>>>> going
>>>> > from
>>>> > >>>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
>>>> > >>>>
>>>> > >>>> In the current release of the IBM MobileFirst, were we have a
>>>> CLI to
>>>> > wrap
>>>> > >>>> cordova commands we had a "$ mfp cordova platform update"
>>>> > >>>> We took a backup of the platform folder and create a zip with a
>>>> > timestamp
>>>> > >>>> (like ios_1457477724404.zip)
>>>> > >>>> We did this just in case the command was destructive and user
>>>> didn't
>>>> > lost
>>>> > >>>> files just in case they didn't have all files checked-in/backup
>>>> > >>>>
>>>> > >>>> So doing a backup would be good if we move forward with this
>>>> > destructive
>>>> > >>>> action of doing a platform remove
>>>> > >>>>
>>>> > >>>>
>>>> > >>>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <
>>>> byoungro.so@intel.com>
>>>> > wrote:
>>>> > >>>>
>>>> > >>>> > I second that. +1
>>>> > >>>> >
>>>> > >>>> > Byoungro So
>>>> > >>>> > SSG / DPD / Mobile Computing and Compilers
>>>> > >>>> > Intel Corporation
>>>> > >>>> >
>>>> > >>>> > From: Anis KADRI <anis.kadri@gmail.com<mailto:
>>>> anis.kadri@gmail.com
>>>> > >>
>>>> > >>>> > Reply-To: "dev@cordova.apache.org<mailto:
>>>> dev@cordova.apache.org>" <
>>>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>>>> > >>>> > Date: Tuesday, March 8, 2016 at 2:34 PM
>>>> > >>>> > To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
>>>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>>>> > >>>> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for
>>>> rm, add
>>>> > in
>>>> > >>>> > cordova-ios
>>>> > >>>> >
>>>> > >>>> > I support this as well. Real updates never work. Better to
>>>> > remove/add.
>>>> > >>>> >
>>>> > >>>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <
>>>> stevengill97@gmail.com
>>>> > >>>> > <ma...@gmail.com>> wrote:
>>>> > >>>> >
>>>> > >>>> > I would also like to see this happen. Would this cause
>>>> problems if
>>>> > we did
>>>> > >>>> > this for other platforms?
>>>> > >>>> >
>>>> > >>>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com
>>>> <mailto:
>>>> > >>>> > shazron@gmail.com>> wrote:
>>>> > >>>> >
>>>> > >>>> > > See:
>>>> > >>>> > >
>>>> >
>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
>>>> > >>>> > >
>>>> > >>>> > > Problem:
>>>> > >>>> > > For cordova-ios, "cordova platform update" does its own
>>>> thing,
>>>> > which
>>>> > >>>> > > causes problems.
>>>> > >>>> > >
>>>> > >>>> > > Proposal:
>>>> > >>>> > > Change "cordova platform update ios@version" to be
>>>> basically an
>>>> > alias
>>>> > >>>> > for:
>>>> > >>>> > > "cordova platform rm ios"
>>>> > >>>> > > "cordova platform add ios@version"
>>>> > >>>> > >
>>>> > >>>> > >
>>>> > ---------------------------------------------------------------------
>>>> > >>>> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>> > <mailto:
>>>> > >>>> > dev-unsubscribe@cordova.apache.org>
>>>> > >>>> > > For additional commands, e-mail: dev-help@cordova.apache.org
>>>> > <mailto:
>>>> > >>>> > dev-help@cordova.apache.org>
>>>> > >>>> > >
>>>> > >>>> > >
>>>> > >>>> >
>>>> > >>>> >
>>>> > >>>> >
>>>> > >>>> >
>>>> > ---------------------------------------------------------------------
>>>> > >>>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>> > >>>> > For additional commands, e-mail: dev-help@cordova.apache.org
>>>> > >>>> >
>>>> > >>>>
>>>> > >>>>
>>>> ---------------------------------------------------------------------
>>>> > >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>> > >>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>> > >>>>
>>>> > >
>>>> > >---------------------------------------------------------------------
>>>> > >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>> > >For additional commands, e-mail: dev-help@cordova.apache.org
>>>> > >
>>>> >
>>>> >
>>>>
>>>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Carlos Santana <cs...@gmail.com>.
Scratch the "migrate cli command" idea. Now I think about it really messy
and it will be another hackHooks.
I think we concentrate to provide more capabilities thru config.xml and
hooks for making migration more smooth.
Like a running hooks on after_platform_update event and providing more
information in the hook context argument with from to platform info
On Tue, Mar 15, 2016 at 9:52 PM Carlos Santana <cs...@gmail.com> wrote:
> By "I like the proposal and deleting all previous versions I don't see as
> an issue." I meant that I don't have an issue if we don't have this feature
> to clean old. I prefer not to have it
>
> On Tue, Mar 15, 2016 at 9:51 PM Carlos Santana <cs...@gmail.com>
> wrote:
>
>> I like the proposal and deleting all previous versions I don't see as an
>> issue.
>>
>> I didn't get the part of using symlinks, I don't symlinks they bring a
>> lot of problems to implement correctly I prefer we stick to real directory
>> and rename directories, user can choose to create symlinks on their needs,
>> we would just handle them.
>>
>> If end up doing a flag I prefer just deleting the one being replace, as
>> --no-backup
>> cordova platform update ios --no-backup (using nopt notation)
>> will do the rename ios -> ios@4.0.1
>> will do the add ios
>> then only then if the add works and all plugins present get install and
>> cli exist with none zero go and don't save the backup and delete the folder
>> that was rename to ios@4.0.1
>>
>> But I agree for now implement default to always do a backup, no flag
>> (maybe experimental)
>>
>> User needs to be explicit on harmful actions, they can do platform rm
>> ios@4.0.1 will simple delete /platforms/ios@4.0.1
>> and he can do it for any platform current/active or old backups
>>
>> I'm OK about this proposal and we can start a new one that covers how to
>> help with migration. Since update becomes backup,
>> We need to think how much we invest in migration, value of cordova is on
>> the runtime (core platform, and plugins)
>>
>> We can do start iterating with implementing enablement but specific
>> migration tasks/actions are built on real experiences by the community.
>> Meaning plugins/extensions that are plugable to handle migration, today
>> peope do with hooks, I call those hackHooks :-), hooks that do hacks to
>> make platforms build artifacts and be able to restore everything that can't
>> be restore with platform+plugins+config.xml
>>
>> So the flow I see if as the following:
>>
>> cordova platform update ios
>> ....
>> mv platforms/ios platforms/ios@4.0.1
>> add platforms/ios
>> ....
>> cordova migrate ios ios@4.0.1
>>
>> This cli migrate command migrate helps user migrate things from 4.0.1
>> (ios@4.0.1) to 4.1 (ios/current)
>> migrate will run the actions/tasks/extensions added by the user, this
>> actions/tasks/extensions (don't have a good name for migrations "things")
>> will be available on npm with keyword cordova:migrate
>> For example there can be a command "migrate add
>> cordova-migrate-entitlements" (this tasks migrate ios entitlements from an
>> old project to a new project)
>> this tasks/extension will be added to list of steps to do to automate
>> migration when cli command migrate runs
>> Cordova project can provide the tooling and maybe a handful (or zero) of
>> well known tasks for migration, but not more, the rest will come from the
>> community/3rd party to maintain and publish, this will be a way for people
>> like Darryl and Tommy that have knowledge on migration and hooks they can
>> convert those to migration npm packages to share.
>>
>>
>>
>>
>>
>>
>> On Mon, Mar 14, 2016 at 8:21 PM Jesse <pu...@gmail.com> wrote:
>>
>>> Yeah, the simple approach is probably the best!
>>>
>>> Move to strike --kill or any variation of it, and let developers delete
>>> what they want to. If it proves to be an issue, then we will address it.
>>>
>>>
>>> @purplecabbage
>>> risingj.com
>>>
>>> On Mon, Mar 14, 2016 at 3:58 PM, Parashuram N <pa...@microsoft.com>
>>> wrote:
>>>
>>> > Instead of adding an entire flag to remove previous versions, does it
>>> make
>>> > sense to have cordova platform android@oldVersion. Alternatively,
>>> users
>>> > could simple use the terminal to delete older versions from the command
>>> > line inside the platform folders.
>>> > If we have users asking for a way to “remove all older platforms”, we
>>> > could then introduce this flag.
>>> >
>>> > On 3/14/16, 2:07 PM, "Shazron" <sh...@gmail.com> wrote:
>>> >
>>> > >Note:
>>> > >I prefer `--remove-previous-versions` to `--kill` so as to be
>>> > >unambiguous and explicit.
>>> > >
>>> > >On Mon, Mar 14, 2016 at 2:01 PM, Shazron <sh...@gmail.com> wrote:
>>> > >> +1 I like it (esp reasons in #2)
>>> > >>
>>> > >> I agree that platform rm+add is not there yet, case in point all the
>>> > >> related issues in the "Issue Links" in this issue:
>>> > >>
>>> >
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
>>> > >>
>>> > >> Some comments:
>>> > >>
>>> > >> `cordova platform ls` should list these previous versions as well.
>>> > >>
>>> > >> `cordova platform add ios` should not delete these previous
>>> versions?
>>> > >>
>>> > >> `cordova platform update ios --kill` kills *all* previous versions,
>>> > >> regardless of major version (clarification)
>>> > >>
>>> > >> `cordova platform rm ios` should just remove the current version so
>>> it
>>> > >> doesn't get confusing. If we have listing of the previous versions
>>> > >> above in `cordova platform ls`, you would have to explicitly do a
>>> > >> `cordova platform rm ios@4.0.1` for example. However, this does not
>>> > >> solve for a way to remove *all* previous versions (we will have to
>>> > >> figure out a new command?)
>>> > >>
>>> > >>
>>> > >> On Mon, Mar 14, 2016 at 1:29 PM, Jesse <pu...@gmail.com>
>>> wrote:
>>> > >>> Considering all of the points previously mentioned, I would like to
>>> > make a
>>> > >>> supplementary proposal.
>>> > >>>
>>> > >>> We seem to all agree that platform rm+add is ideal in a world
>>> where we
>>> > can
>>> > >>> truly consider platforms as artifacts, but we are really not there
>>> yet.
>>> > >>> The zipped snapshot of the platform before the update that Carlos
>>> > mentions
>>> > >>> is a good non-destructive way of allowing a developer the chance to
>>> > always
>>> > >>> go back.
>>> > >>> I would like to take this approach one step further and suggest:
>>> > >>> (note: I am using 'ios' as the example platform, but this applies
>>> to
>>> > >>> any/all platforms )
>>> > >>>
>>> > >>> 1. when updating a project, we rename the previous platforms/ios/
>>> to
>>> > >>> include the version it was, and leave it in the platforms folder.
>>> > >>> ex. platforms/ios/ -> platforms/ios@4.0.1/
>>> > >>>
>>> > >>> 2. platforms/ios would always contain the latest ios version
>>> installed
>>> > for
>>> > >>> this project. This would allow most tooling to work unchanged, and
>>> > >>> sidesteps symlink issues on windows with things like ios-latest ->
>>> > ios@4.02
>>> > >>>
>>> > >>> 3. [optional or stretch goal] 'platform rm ios' could be used to go
>>> > back to
>>> > >>> the previous 'current' version ( according to semver ) or should
>>> this
>>> > be a
>>> > >>> new command? like 'cordova platform pop ios' ?
>>> > >>>
>>> > >>> 4. we can add a flag to platform update ios --kill to do a
>>> destructive
>>> > >>> update for users who know that that is what they want.
>>> > >>>
>>> > >>> 5. [optional | stretch ] allow build/run of platform artifacts as
>>> > well, so
>>> > >>> developers can run commands like : 'cordova run ios@4.0.1'
>>> > >>>
>>> > >>> 6. the platform listed in config.xml would always be the latest
>>> one,
>>> > >>> regardless of how many artifacts were still around.
>>> > >>>
>>> > >>> Thoughts? Issues? Comments?
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>> @purplecabbage
>>> > >>>
>>> >
>>> https://na01.safelinks.protection.outlook.com/?url=risingj.com&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AYCfungKQfswLZClqFCBX2oacLlJixX8xOGAFiJjJcQ%3d
>>> > >>>
>>> > >>> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <dan@cellartracker.com
>>> >
>>> > wrote:
>>> > >>>
>>> > >>>> As a user of cordova (and list lurker), I thought I'd chime in
>>> and say
>>> > >>>> Carlos hit on some very good points. In theory I like the idea of
>>> > treating
>>> > >>>> platforms like build artifacts, but in reality -- at least for my
>>> > current
>>> > >>>> usage -- things are far from that. Making this type of change will
>>> > make my
>>> > >>>> upgrades more challenging. I'm willing to live with that, but
>>> PLEASE
>>> > make
>>> > >>>> sure you do a backup (or tell the user to) "just in case" before
>>> > nuking
>>> > >>>> their directory.
>>> > >>>>
>>> > >>>> Right now, I find I do more native (non CLI) development on iOS
>>> > compared
>>> > >>>> to other platforms. I'd have to do a full inventory of all of my
>>> > native
>>> > >>>> customizations, but as Carlos mentions it is a combination of:
>>> > >>>>
>>> > >>>> - working around bugs/limitations in the tools
>>> > >>>> - additional AppDelegate customizations for native analytics
>>> > libraries and
>>> > >>>> error handling as our app is remotely hosted
>>> > >>>> - the addition of dependencies as cocoapods
>>> > >>>> - other build/plist customizations which are far simpler to modify
>>> > >>>> directly, e.g. adding an entitlements file to support universal
>>> > links, or
>>> > >>>> adding ITSEncryptionExportComplianceCode to the plist to simplify
>>> app
>>> > >>>> submissions
>>> > >>>>
>>> > >>>> Anyway, please just keep in mind those of us who may be doing
>>> things
>>> > the
>>> > >>>> "old way" as you move forward here.
>>> > >>>>
>>> > >>>> Dan
>>> > >>>>
>>> > >>>> -----Original Message-----
>>> > >>>> From: Carlos Santana [mailto:csantana23@gmail.com]
>>> > >>>> Sent: Tuesday, March 08, 2016 3:16 PM
>>> > >>>> To: dev@cordova.apache.org
>>> > >>>> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm,
>>> add in
>>> > >>>> cordova-ios
>>> > >>>>
>>> > >>>> I was never a fan of the "platform update" command since it was
>>> not
>>> > fully
>>> > >>>> tested across the board.
>>> > >>>> like all the permutations possible to/from upgrade. meaning going
>>> for
>>> > very
>>> > >>>> old like 3.6 to 5.1
>>> > >>>>
>>> > >>>> If we do this I think it will break a lot of people that got used
>>> to
>>> > >>>> changing files inside platform/ios/ in terms of changing XCode
>>> > settings in
>>> > >>>> pbxproj like:
>>> > >>>> - use story board to launch app to be able to support ipad pro
>>> > >>>> - some initialization code in AppDelegate
>>> > >>>> - Any native code they added like NativeUI to mix web and native
>>> > >>>> - Changes to StoryBoard to adjust webview inside native view
>>> > >>>> - Build and Signing settings in project or target in XCode
>>> > >>>> - Installation of cocoapods
>>> > >>>> - Xcode Build phases scripts
>>> > >>>>
>>> > >>>> Meaning that they will need to restore or generate all this things
>>> > with
>>> > >>>> hooks or plugins.
>>> > >>>>
>>> > >>>> I know that Darryl Pogue and Tommy have projects where they can
>>> > >>>> successfully treat platfforms folder as 100% build artifact that
>>> they
>>> > can
>>> > >>>> throw away. But to get there is not super easy
>>> > >>>>
>>> > >>>> "platform update ios" has being scoped to only touch the
>>> CordovaLib
>>> > xcode
>>> > >>>> project, leaving the app xcode project not touched that's why it's
>>> > being
>>> > >>>> safe all along
>>> > >>>>
>>> > >>>> What was the root cause of the recent problems with 4.1.0 for
>>> update?
>>> > >>>>
>>> > >>>> Maybe we can restrict update command to major version, meaning
>>> going
>>> > from
>>> > >>>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
>>> > >>>>
>>> > >>>> In the current release of the IBM MobileFirst, were we have a CLI
>>> to
>>> > wrap
>>> > >>>> cordova commands we had a "$ mfp cordova platform update"
>>> > >>>> We took a backup of the platform folder and create a zip with a
>>> > timestamp
>>> > >>>> (like ios_1457477724404.zip)
>>> > >>>> We did this just in case the command was destructive and user
>>> didn't
>>> > lost
>>> > >>>> files just in case they didn't have all files checked-in/backup
>>> > >>>>
>>> > >>>> So doing a backup would be good if we move forward with this
>>> > destructive
>>> > >>>> action of doing a platform remove
>>> > >>>>
>>> > >>>>
>>> > >>>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <
>>> byoungro.so@intel.com>
>>> > wrote:
>>> > >>>>
>>> > >>>> > I second that. +1
>>> > >>>> >
>>> > >>>> > Byoungro So
>>> > >>>> > SSG / DPD / Mobile Computing and Compilers
>>> > >>>> > Intel Corporation
>>> > >>>> >
>>> > >>>> > From: Anis KADRI <anis.kadri@gmail.com<mailto:
>>> anis.kadri@gmail.com
>>> > >>
>>> > >>>> > Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>"
>>> <
>>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>>> > >>>> > Date: Tuesday, March 8, 2016 at 2:34 PM
>>> > >>>> > To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
>>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>>> > >>>> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm,
>>> add
>>> > in
>>> > >>>> > cordova-ios
>>> > >>>> >
>>> > >>>> > I support this as well. Real updates never work. Better to
>>> > remove/add.
>>> > >>>> >
>>> > >>>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <
>>> stevengill97@gmail.com
>>> > >>>> > <ma...@gmail.com>> wrote:
>>> > >>>> >
>>> > >>>> > I would also like to see this happen. Would this cause problems
>>> if
>>> > we did
>>> > >>>> > this for other platforms?
>>> > >>>> >
>>> > >>>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com
>>> <mailto:
>>> > >>>> > shazron@gmail.com>> wrote:
>>> > >>>> >
>>> > >>>> > > See:
>>> > >>>> > >
>>> >
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
>>> > >>>> > >
>>> > >>>> > > Problem:
>>> > >>>> > > For cordova-ios, "cordova platform update" does its own thing,
>>> > which
>>> > >>>> > > causes problems.
>>> > >>>> > >
>>> > >>>> > > Proposal:
>>> > >>>> > > Change "cordova platform update ios@version" to be basically
>>> an
>>> > alias
>>> > >>>> > for:
>>> > >>>> > > "cordova platform rm ios"
>>> > >>>> > > "cordova platform add ios@version"
>>> > >>>> > >
>>> > >>>> > >
>>> > ---------------------------------------------------------------------
>>> > >>>> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> > <mailto:
>>> > >>>> > dev-unsubscribe@cordova.apache.org>
>>> > >>>> > > For additional commands, e-mail: dev-help@cordova.apache.org
>>> > <mailto:
>>> > >>>> > dev-help@cordova.apache.org>
>>> > >>>> > >
>>> > >>>> > >
>>> > >>>> >
>>> > >>>> >
>>> > >>>> >
>>> > >>>> >
>>> > ---------------------------------------------------------------------
>>> > >>>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> > >>>> > For additional commands, e-mail: dev-help@cordova.apache.org
>>> > >>>> >
>>> > >>>>
>>> > >>>>
>>> ---------------------------------------------------------------------
>>> > >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> > >>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>> > >>>>
>>> > >
>>> > >---------------------------------------------------------------------
>>> > >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> > >For additional commands, e-mail: dev-help@cordova.apache.org
>>> > >
>>> >
>>> >
>>>
>>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Carlos Santana <cs...@gmail.com>.
By "I like the proposal and deleting all previous versions I don't see as
an issue." I meant that I don't have an issue if we don't have this feature
to clean old. I prefer not to have it
On Tue, Mar 15, 2016 at 9:51 PM Carlos Santana <cs...@gmail.com> wrote:
> I like the proposal and deleting all previous versions I don't see as an
> issue.
>
> I didn't get the part of using symlinks, I don't symlinks they bring a lot
> of problems to implement correctly I prefer we stick to real directory and
> rename directories, user can choose to create symlinks on their needs, we
> would just handle them.
>
> If end up doing a flag I prefer just deleting the one being replace, as
> --no-backup
> cordova platform update ios --no-backup (using nopt notation)
> will do the rename ios -> ios@4.0.1
> will do the add ios
> then only then if the add works and all plugins present get install and
> cli exist with none zero go and don't save the backup and delete the folder
> that was rename to ios@4.0.1
>
> But I agree for now implement default to always do a backup, no flag
> (maybe experimental)
>
> User needs to be explicit on harmful actions, they can do platform rm
> ios@4.0.1 will simple delete /platforms/ios@4.0.1
> and he can do it for any platform current/active or old backups
>
> I'm OK about this proposal and we can start a new one that covers how to
> help with migration. Since update becomes backup,
> We need to think how much we invest in migration, value of cordova is on
> the runtime (core platform, and plugins)
>
> We can do start iterating with implementing enablement but specific
> migration tasks/actions are built on real experiences by the community.
> Meaning plugins/extensions that are plugable to handle migration, today
> peope do with hooks, I call those hackHooks :-), hooks that do hacks to
> make platforms build artifacts and be able to restore everything that can't
> be restore with platform+plugins+config.xml
>
> So the flow I see if as the following:
>
> cordova platform update ios
> ....
> mv platforms/ios platforms/ios@4.0.1
> add platforms/ios
> ....
> cordova migrate ios ios@4.0.1
>
> This cli migrate command migrate helps user migrate things from 4.0.1
> (ios@4.0.1) to 4.1 (ios/current)
> migrate will run the actions/tasks/extensions added by the user, this
> actions/tasks/extensions (don't have a good name for migrations "things")
> will be available on npm with keyword cordova:migrate
> For example there can be a command "migrate add
> cordova-migrate-entitlements" (this tasks migrate ios entitlements from an
> old project to a new project)
> this tasks/extension will be added to list of steps to do to automate
> migration when cli command migrate runs
> Cordova project can provide the tooling and maybe a handful (or zero) of
> well known tasks for migration, but not more, the rest will come from the
> community/3rd party to maintain and publish, this will be a way for people
> like Darryl and Tommy that have knowledge on migration and hooks they can
> convert those to migration npm packages to share.
>
>
>
>
>
>
> On Mon, Mar 14, 2016 at 8:21 PM Jesse <pu...@gmail.com> wrote:
>
>> Yeah, the simple approach is probably the best!
>>
>> Move to strike --kill or any variation of it, and let developers delete
>> what they want to. If it proves to be an issue, then we will address it.
>>
>>
>> @purplecabbage
>> risingj.com
>>
>> On Mon, Mar 14, 2016 at 3:58 PM, Parashuram N <pa...@microsoft.com>
>> wrote:
>>
>> > Instead of adding an entire flag to remove previous versions, does it
>> make
>> > sense to have cordova platform android@oldVersion. Alternatively, users
>> > could simple use the terminal to delete older versions from the command
>> > line inside the platform folders.
>> > If we have users asking for a way to “remove all older platforms”, we
>> > could then introduce this flag.
>> >
>> > On 3/14/16, 2:07 PM, "Shazron" <sh...@gmail.com> wrote:
>> >
>> > >Note:
>> > >I prefer `--remove-previous-versions` to `--kill` so as to be
>> > >unambiguous and explicit.
>> > >
>> > >On Mon, Mar 14, 2016 at 2:01 PM, Shazron <sh...@gmail.com> wrote:
>> > >> +1 I like it (esp reasons in #2)
>> > >>
>> > >> I agree that platform rm+add is not there yet, case in point all the
>> > >> related issues in the "Issue Links" in this issue:
>> > >>
>> >
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
>> > >>
>> > >> Some comments:
>> > >>
>> > >> `cordova platform ls` should list these previous versions as well.
>> > >>
>> > >> `cordova platform add ios` should not delete these previous versions?
>> > >>
>> > >> `cordova platform update ios --kill` kills *all* previous versions,
>> > >> regardless of major version (clarification)
>> > >>
>> > >> `cordova platform rm ios` should just remove the current version so
>> it
>> > >> doesn't get confusing. If we have listing of the previous versions
>> > >> above in `cordova platform ls`, you would have to explicitly do a
>> > >> `cordova platform rm ios@4.0.1` for example. However, this does not
>> > >> solve for a way to remove *all* previous versions (we will have to
>> > >> figure out a new command?)
>> > >>
>> > >>
>> > >> On Mon, Mar 14, 2016 at 1:29 PM, Jesse <pu...@gmail.com>
>> wrote:
>> > >>> Considering all of the points previously mentioned, I would like to
>> > make a
>> > >>> supplementary proposal.
>> > >>>
>> > >>> We seem to all agree that platform rm+add is ideal in a world where
>> we
>> > can
>> > >>> truly consider platforms as artifacts, but we are really not there
>> yet.
>> > >>> The zipped snapshot of the platform before the update that Carlos
>> > mentions
>> > >>> is a good non-destructive way of allowing a developer the chance to
>> > always
>> > >>> go back.
>> > >>> I would like to take this approach one step further and suggest:
>> > >>> (note: I am using 'ios' as the example platform, but this applies
>> to
>> > >>> any/all platforms )
>> > >>>
>> > >>> 1. when updating a project, we rename the previous platforms/ios/ to
>> > >>> include the version it was, and leave it in the platforms folder.
>> > >>> ex. platforms/ios/ -> platforms/ios@4.0.1/
>> > >>>
>> > >>> 2. platforms/ios would always contain the latest ios version
>> installed
>> > for
>> > >>> this project. This would allow most tooling to work unchanged, and
>> > >>> sidesteps symlink issues on windows with things like ios-latest ->
>> > ios@4.02
>> > >>>
>> > >>> 3. [optional or stretch goal] 'platform rm ios' could be used to go
>> > back to
>> > >>> the previous 'current' version ( according to semver ) or should
>> this
>> > be a
>> > >>> new command? like 'cordova platform pop ios' ?
>> > >>>
>> > >>> 4. we can add a flag to platform update ios --kill to do a
>> destructive
>> > >>> update for users who know that that is what they want.
>> > >>>
>> > >>> 5. [optional | stretch ] allow build/run of platform artifacts as
>> > well, so
>> > >>> developers can run commands like : 'cordova run ios@4.0.1'
>> > >>>
>> > >>> 6. the platform listed in config.xml would always be the latest one,
>> > >>> regardless of how many artifacts were still around.
>> > >>>
>> > >>> Thoughts? Issues? Comments?
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >>> @purplecabbage
>> > >>>
>> >
>> https://na01.safelinks.protection.outlook.com/?url=risingj.com&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AYCfungKQfswLZClqFCBX2oacLlJixX8xOGAFiJjJcQ%3d
>> > >>>
>> > >>> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <da...@cellartracker.com>
>> > wrote:
>> > >>>
>> > >>>> As a user of cordova (and list lurker), I thought I'd chime in and
>> say
>> > >>>> Carlos hit on some very good points. In theory I like the idea of
>> > treating
>> > >>>> platforms like build artifacts, but in reality -- at least for my
>> > current
>> > >>>> usage -- things are far from that. Making this type of change will
>> > make my
>> > >>>> upgrades more challenging. I'm willing to live with that, but
>> PLEASE
>> > make
>> > >>>> sure you do a backup (or tell the user to) "just in case" before
>> > nuking
>> > >>>> their directory.
>> > >>>>
>> > >>>> Right now, I find I do more native (non CLI) development on iOS
>> > compared
>> > >>>> to other platforms. I'd have to do a full inventory of all of my
>> > native
>> > >>>> customizations, but as Carlos mentions it is a combination of:
>> > >>>>
>> > >>>> - working around bugs/limitations in the tools
>> > >>>> - additional AppDelegate customizations for native analytics
>> > libraries and
>> > >>>> error handling as our app is remotely hosted
>> > >>>> - the addition of dependencies as cocoapods
>> > >>>> - other build/plist customizations which are far simpler to modify
>> > >>>> directly, e.g. adding an entitlements file to support universal
>> > links, or
>> > >>>> adding ITSEncryptionExportComplianceCode to the plist to simplify
>> app
>> > >>>> submissions
>> > >>>>
>> > >>>> Anyway, please just keep in mind those of us who may be doing
>> things
>> > the
>> > >>>> "old way" as you move forward here.
>> > >>>>
>> > >>>> Dan
>> > >>>>
>> > >>>> -----Original Message-----
>> > >>>> From: Carlos Santana [mailto:csantana23@gmail.com]
>> > >>>> Sent: Tuesday, March 08, 2016 3:16 PM
>> > >>>> To: dev@cordova.apache.org
>> > >>>> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm,
>> add in
>> > >>>> cordova-ios
>> > >>>>
>> > >>>> I was never a fan of the "platform update" command since it was not
>> > fully
>> > >>>> tested across the board.
>> > >>>> like all the permutations possible to/from upgrade. meaning going
>> for
>> > very
>> > >>>> old like 3.6 to 5.1
>> > >>>>
>> > >>>> If we do this I think it will break a lot of people that got used
>> to
>> > >>>> changing files inside platform/ios/ in terms of changing XCode
>> > settings in
>> > >>>> pbxproj like:
>> > >>>> - use story board to launch app to be able to support ipad pro
>> > >>>> - some initialization code in AppDelegate
>> > >>>> - Any native code they added like NativeUI to mix web and native
>> > >>>> - Changes to StoryBoard to adjust webview inside native view
>> > >>>> - Build and Signing settings in project or target in XCode
>> > >>>> - Installation of cocoapods
>> > >>>> - Xcode Build phases scripts
>> > >>>>
>> > >>>> Meaning that they will need to restore or generate all this things
>> > with
>> > >>>> hooks or plugins.
>> > >>>>
>> > >>>> I know that Darryl Pogue and Tommy have projects where they can
>> > >>>> successfully treat platfforms folder as 100% build artifact that
>> they
>> > can
>> > >>>> throw away. But to get there is not super easy
>> > >>>>
>> > >>>> "platform update ios" has being scoped to only touch the CordovaLib
>> > xcode
>> > >>>> project, leaving the app xcode project not touched that's why it's
>> > being
>> > >>>> safe all along
>> > >>>>
>> > >>>> What was the root cause of the recent problems with 4.1.0 for
>> update?
>> > >>>>
>> > >>>> Maybe we can restrict update command to major version, meaning
>> going
>> > from
>> > >>>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
>> > >>>>
>> > >>>> In the current release of the IBM MobileFirst, were we have a CLI
>> to
>> > wrap
>> > >>>> cordova commands we had a "$ mfp cordova platform update"
>> > >>>> We took a backup of the platform folder and create a zip with a
>> > timestamp
>> > >>>> (like ios_1457477724404.zip)
>> > >>>> We did this just in case the command was destructive and user
>> didn't
>> > lost
>> > >>>> files just in case they didn't have all files checked-in/backup
>> > >>>>
>> > >>>> So doing a backup would be good if we move forward with this
>> > destructive
>> > >>>> action of doing a platform remove
>> > >>>>
>> > >>>>
>> > >>>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <byoungro.so@intel.com
>> >
>> > wrote:
>> > >>>>
>> > >>>> > I second that. +1
>> > >>>> >
>> > >>>> > Byoungro So
>> > >>>> > SSG / DPD / Mobile Computing and Compilers
>> > >>>> > Intel Corporation
>> > >>>> >
>> > >>>> > From: Anis KADRI <anis.kadri@gmail.com<mailto:
>> anis.kadri@gmail.com
>> > >>
>> > >>>> > Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>"
>> <
>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>> > >>>> > Date: Tuesday, March 8, 2016 at 2:34 PM
>> > >>>> > To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
>> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>> > >>>> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm,
>> add
>> > in
>> > >>>> > cordova-ios
>> > >>>> >
>> > >>>> > I support this as well. Real updates never work. Better to
>> > remove/add.
>> > >>>> >
>> > >>>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <
>> stevengill97@gmail.com
>> > >>>> > <ma...@gmail.com>> wrote:
>> > >>>> >
>> > >>>> > I would also like to see this happen. Would this cause problems
>> if
>> > we did
>> > >>>> > this for other platforms?
>> > >>>> >
>> > >>>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com
>> <mailto:
>> > >>>> > shazron@gmail.com>> wrote:
>> > >>>> >
>> > >>>> > > See:
>> > >>>> > >
>> >
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
>> > >>>> > >
>> > >>>> > > Problem:
>> > >>>> > > For cordova-ios, "cordova platform update" does its own thing,
>> > which
>> > >>>> > > causes problems.
>> > >>>> > >
>> > >>>> > > Proposal:
>> > >>>> > > Change "cordova platform update ios@version" to be basically
>> an
>> > alias
>> > >>>> > for:
>> > >>>> > > "cordova platform rm ios"
>> > >>>> > > "cordova platform add ios@version"
>> > >>>> > >
>> > >>>> > >
>> > ---------------------------------------------------------------------
>> > >>>> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > <mailto:
>> > >>>> > dev-unsubscribe@cordova.apache.org>
>> > >>>> > > For additional commands, e-mail: dev-help@cordova.apache.org
>> > <mailto:
>> > >>>> > dev-help@cordova.apache.org>
>> > >>>> > >
>> > >>>> > >
>> > >>>> >
>> > >>>> >
>> > >>>> >
>> > >>>> >
>> > ---------------------------------------------------------------------
>> > >>>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > >>>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> > >>>> >
>> > >>>>
>> > >>>>
>> ---------------------------------------------------------------------
>> > >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > >>>> For additional commands, e-mail: dev-help@cordova.apache.org
>> > >>>>
>> > >
>> > >---------------------------------------------------------------------
>> > >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > >For additional commands, e-mail: dev-help@cordova.apache.org
>> > >
>> >
>> >
>>
>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Carlos Santana <cs...@gmail.com>.
I like the proposal and deleting all previous versions I don't see as an
issue.
I didn't get the part of using symlinks, I don't symlinks they bring a lot
of problems to implement correctly I prefer we stick to real directory and
rename directories, user can choose to create symlinks on their needs, we
would just handle them.
If end up doing a flag I prefer just deleting the one being replace, as
--no-backup
cordova platform update ios --no-backup (using nopt notation)
will do the rename ios -> ios@4.0.1
will do the add ios
then only then if the add works and all plugins present get install and cli
exist with none zero go and don't save the backup and delete the folder
that was rename to ios@4.0.1
But I agree for now implement default to always do a backup, no flag (maybe
experimental)
User needs to be explicit on harmful actions, they can do platform rm
ios@4.0.1 will simple delete /platforms/ios@4.0.1
and he can do it for any platform current/active or old backups
I'm OK about this proposal and we can start a new one that covers how to
help with migration. Since update becomes backup,
We need to think how much we invest in migration, value of cordova is on
the runtime (core platform, and plugins)
We can do start iterating with implementing enablement but specific
migration tasks/actions are built on real experiences by the community.
Meaning plugins/extensions that are plugable to handle migration, today
peope do with hooks, I call those hackHooks :-), hooks that do hacks to
make platforms build artifacts and be able to restore everything that can't
be restore with platform+plugins+config.xml
So the flow I see if as the following:
cordova platform update ios
....
mv platforms/ios platforms/ios@4.0.1
add platforms/ios
....
cordova migrate ios ios@4.0.1
This cli migrate command migrate helps user migrate things from 4.0.1
(ios@4.0.1) to 4.1 (ios/current)
migrate will run the actions/tasks/extensions added by the user, this
actions/tasks/extensions (don't have a good name for migrations "things")
will be available on npm with keyword cordova:migrate
For example there can be a command "migrate add
cordova-migrate-entitlements" (this tasks migrate ios entitlements from an
old project to a new project)
this tasks/extension will be added to list of steps to do to automate
migration when cli command migrate runs
Cordova project can provide the tooling and maybe a handful (or zero) of
well known tasks for migration, but not more, the rest will come from the
community/3rd party to maintain and publish, this will be a way for people
like Darryl and Tommy that have knowledge on migration and hooks they can
convert those to migration npm packages to share.
On Mon, Mar 14, 2016 at 8:21 PM Jesse <pu...@gmail.com> wrote:
> Yeah, the simple approach is probably the best!
>
> Move to strike --kill or any variation of it, and let developers delete
> what they want to. If it proves to be an issue, then we will address it.
>
>
> @purplecabbage
> risingj.com
>
> On Mon, Mar 14, 2016 at 3:58 PM, Parashuram N <pa...@microsoft.com>
> wrote:
>
> > Instead of adding an entire flag to remove previous versions, does it
> make
> > sense to have cordova platform android@oldVersion. Alternatively, users
> > could simple use the terminal to delete older versions from the command
> > line inside the platform folders.
> > If we have users asking for a way to “remove all older platforms”, we
> > could then introduce this flag.
> >
> > On 3/14/16, 2:07 PM, "Shazron" <sh...@gmail.com> wrote:
> >
> > >Note:
> > >I prefer `--remove-previous-versions` to `--kill` so as to be
> > >unambiguous and explicit.
> > >
> > >On Mon, Mar 14, 2016 at 2:01 PM, Shazron <sh...@gmail.com> wrote:
> > >> +1 I like it (esp reasons in #2)
> > >>
> > >> I agree that platform rm+add is not there yet, case in point all the
> > >> related issues in the "Issue Links" in this issue:
> > >>
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
> > >>
> > >> Some comments:
> > >>
> > >> `cordova platform ls` should list these previous versions as well.
> > >>
> > >> `cordova platform add ios` should not delete these previous versions?
> > >>
> > >> `cordova platform update ios --kill` kills *all* previous versions,
> > >> regardless of major version (clarification)
> > >>
> > >> `cordova platform rm ios` should just remove the current version so it
> > >> doesn't get confusing. If we have listing of the previous versions
> > >> above in `cordova platform ls`, you would have to explicitly do a
> > >> `cordova platform rm ios@4.0.1` for example. However, this does not
> > >> solve for a way to remove *all* previous versions (we will have to
> > >> figure out a new command?)
> > >>
> > >>
> > >> On Mon, Mar 14, 2016 at 1:29 PM, Jesse <pu...@gmail.com>
> wrote:
> > >>> Considering all of the points previously mentioned, I would like to
> > make a
> > >>> supplementary proposal.
> > >>>
> > >>> We seem to all agree that platform rm+add is ideal in a world where
> we
> > can
> > >>> truly consider platforms as artifacts, but we are really not there
> yet.
> > >>> The zipped snapshot of the platform before the update that Carlos
> > mentions
> > >>> is a good non-destructive way of allowing a developer the chance to
> > always
> > >>> go back.
> > >>> I would like to take this approach one step further and suggest:
> > >>> (note: I am using 'ios' as the example platform, but this applies to
> > >>> any/all platforms )
> > >>>
> > >>> 1. when updating a project, we rename the previous platforms/ios/ to
> > >>> include the version it was, and leave it in the platforms folder.
> > >>> ex. platforms/ios/ -> platforms/ios@4.0.1/
> > >>>
> > >>> 2. platforms/ios would always contain the latest ios version
> installed
> > for
> > >>> this project. This would allow most tooling to work unchanged, and
> > >>> sidesteps symlink issues on windows with things like ios-latest ->
> > ios@4.02
> > >>>
> > >>> 3. [optional or stretch goal] 'platform rm ios' could be used to go
> > back to
> > >>> the previous 'current' version ( according to semver ) or should this
> > be a
> > >>> new command? like 'cordova platform pop ios' ?
> > >>>
> > >>> 4. we can add a flag to platform update ios --kill to do a
> destructive
> > >>> update for users who know that that is what they want.
> > >>>
> > >>> 5. [optional | stretch ] allow build/run of platform artifacts as
> > well, so
> > >>> developers can run commands like : 'cordova run ios@4.0.1'
> > >>>
> > >>> 6. the platform listed in config.xml would always be the latest one,
> > >>> regardless of how many artifacts were still around.
> > >>>
> > >>> Thoughts? Issues? Comments?
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> @purplecabbage
> > >>>
> >
> https://na01.safelinks.protection.outlook.com/?url=risingj.com&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AYCfungKQfswLZClqFCBX2oacLlJixX8xOGAFiJjJcQ%3d
> > >>>
> > >>> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <da...@cellartracker.com>
> > wrote:
> > >>>
> > >>>> As a user of cordova (and list lurker), I thought I'd chime in and
> say
> > >>>> Carlos hit on some very good points. In theory I like the idea of
> > treating
> > >>>> platforms like build artifacts, but in reality -- at least for my
> > current
> > >>>> usage -- things are far from that. Making this type of change will
> > make my
> > >>>> upgrades more challenging. I'm willing to live with that, but PLEASE
> > make
> > >>>> sure you do a backup (or tell the user to) "just in case" before
> > nuking
> > >>>> their directory.
> > >>>>
> > >>>> Right now, I find I do more native (non CLI) development on iOS
> > compared
> > >>>> to other platforms. I'd have to do a full inventory of all of my
> > native
> > >>>> customizations, but as Carlos mentions it is a combination of:
> > >>>>
> > >>>> - working around bugs/limitations in the tools
> > >>>> - additional AppDelegate customizations for native analytics
> > libraries and
> > >>>> error handling as our app is remotely hosted
> > >>>> - the addition of dependencies as cocoapods
> > >>>> - other build/plist customizations which are far simpler to modify
> > >>>> directly, e.g. adding an entitlements file to support universal
> > links, or
> > >>>> adding ITSEncryptionExportComplianceCode to the plist to simplify
> app
> > >>>> submissions
> > >>>>
> > >>>> Anyway, please just keep in mind those of us who may be doing things
> > the
> > >>>> "old way" as you move forward here.
> > >>>>
> > >>>> Dan
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Carlos Santana [mailto:csantana23@gmail.com]
> > >>>> Sent: Tuesday, March 08, 2016 3:16 PM
> > >>>> To: dev@cordova.apache.org
> > >>>> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add
> in
> > >>>> cordova-ios
> > >>>>
> > >>>> I was never a fan of the "platform update" command since it was not
> > fully
> > >>>> tested across the board.
> > >>>> like all the permutations possible to/from upgrade. meaning going
> for
> > very
> > >>>> old like 3.6 to 5.1
> > >>>>
> > >>>> If we do this I think it will break a lot of people that got used to
> > >>>> changing files inside platform/ios/ in terms of changing XCode
> > settings in
> > >>>> pbxproj like:
> > >>>> - use story board to launch app to be able to support ipad pro
> > >>>> - some initialization code in AppDelegate
> > >>>> - Any native code they added like NativeUI to mix web and native
> > >>>> - Changes to StoryBoard to adjust webview inside native view
> > >>>> - Build and Signing settings in project or target in XCode
> > >>>> - Installation of cocoapods
> > >>>> - Xcode Build phases scripts
> > >>>>
> > >>>> Meaning that they will need to restore or generate all this things
> > with
> > >>>> hooks or plugins.
> > >>>>
> > >>>> I know that Darryl Pogue and Tommy have projects where they can
> > >>>> successfully treat platfforms folder as 100% build artifact that
> they
> > can
> > >>>> throw away. But to get there is not super easy
> > >>>>
> > >>>> "platform update ios" has being scoped to only touch the CordovaLib
> > xcode
> > >>>> project, leaving the app xcode project not touched that's why it's
> > being
> > >>>> safe all along
> > >>>>
> > >>>> What was the root cause of the recent problems with 4.1.0 for
> update?
> > >>>>
> > >>>> Maybe we can restrict update command to major version, meaning
> going
> > from
> > >>>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
> > >>>>
> > >>>> In the current release of the IBM MobileFirst, were we have a CLI to
> > wrap
> > >>>> cordova commands we had a "$ mfp cordova platform update"
> > >>>> We took a backup of the platform folder and create a zip with a
> > timestamp
> > >>>> (like ios_1457477724404.zip)
> > >>>> We did this just in case the command was destructive and user didn't
> > lost
> > >>>> files just in case they didn't have all files checked-in/backup
> > >>>>
> > >>>> So doing a backup would be good if we move forward with this
> > destructive
> > >>>> action of doing a platform remove
> > >>>>
> > >>>>
> > >>>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <by...@intel.com>
> > wrote:
> > >>>>
> > >>>> > I second that. +1
> > >>>> >
> > >>>> > Byoungro So
> > >>>> > SSG / DPD / Mobile Computing and Compilers
> > >>>> > Intel Corporation
> > >>>> >
> > >>>> > From: Anis KADRI <anis.kadri@gmail.com<mailto:
> anis.kadri@gmail.com
> > >>
> > >>>> > Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>"
> <
> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> > >>>> > Date: Tuesday, March 8, 2016 at 2:34 PM
> > >>>> > To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> > >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> > >>>> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm,
> add
> > in
> > >>>> > cordova-ios
> > >>>> >
> > >>>> > I support this as well. Real updates never work. Better to
> > remove/add.
> > >>>> >
> > >>>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <
> stevengill97@gmail.com
> > >>>> > <ma...@gmail.com>> wrote:
> > >>>> >
> > >>>> > I would also like to see this happen. Would this cause problems if
> > we did
> > >>>> > this for other platforms?
> > >>>> >
> > >>>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com
> <mailto:
> > >>>> > shazron@gmail.com>> wrote:
> > >>>> >
> > >>>> > > See:
> > >>>> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
> > >>>> > >
> > >>>> > > Problem:
> > >>>> > > For cordova-ios, "cordova platform update" does its own thing,
> > which
> > >>>> > > causes problems.
> > >>>> > >
> > >>>> > > Proposal:
> > >>>> > > Change "cordova platform update ios@version" to be basically an
> > alias
> > >>>> > for:
> > >>>> > > "cordova platform rm ios"
> > >>>> > > "cordova platform add ios@version"
> > >>>> > >
> > >>>> > >
> > ---------------------------------------------------------------------
> > >>>> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > <mailto:
> > >>>> > dev-unsubscribe@cordova.apache.org>
> > >>>> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > <mailto:
> > >>>> > dev-help@cordova.apache.org>
> > >>>> > >
> > >>>> > >
> > >>>> >
> > >>>> >
> > >>>> >
> > >>>> >
> > ---------------------------------------------------------------------
> > >>>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >>>> > For additional commands, e-mail: dev-help@cordova.apache.org
> > >>>> >
> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>>>
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> >
> >
>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Jesse <pu...@gmail.com>.
Yeah, the simple approach is probably the best!
Move to strike --kill or any variation of it, and let developers delete
what they want to. If it proves to be an issue, then we will address it.
@purplecabbage
risingj.com
On Mon, Mar 14, 2016 at 3:58 PM, Parashuram N <pa...@microsoft.com>
wrote:
> Instead of adding an entire flag to remove previous versions, does it make
> sense to have cordova platform android@oldVersion. Alternatively, users
> could simple use the terminal to delete older versions from the command
> line inside the platform folders.
> If we have users asking for a way to “remove all older platforms”, we
> could then introduce this flag.
>
> On 3/14/16, 2:07 PM, "Shazron" <sh...@gmail.com> wrote:
>
> >Note:
> >I prefer `--remove-previous-versions` to `--kill` so as to be
> >unambiguous and explicit.
> >
> >On Mon, Mar 14, 2016 at 2:01 PM, Shazron <sh...@gmail.com> wrote:
> >> +1 I like it (esp reasons in #2)
> >>
> >> I agree that platform rm+add is not there yet, case in point all the
> >> related issues in the "Issue Links" in this issue:
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
> >>
> >> Some comments:
> >>
> >> `cordova platform ls` should list these previous versions as well.
> >>
> >> `cordova platform add ios` should not delete these previous versions?
> >>
> >> `cordova platform update ios --kill` kills *all* previous versions,
> >> regardless of major version (clarification)
> >>
> >> `cordova platform rm ios` should just remove the current version so it
> >> doesn't get confusing. If we have listing of the previous versions
> >> above in `cordova platform ls`, you would have to explicitly do a
> >> `cordova platform rm ios@4.0.1` for example. However, this does not
> >> solve for a way to remove *all* previous versions (we will have to
> >> figure out a new command?)
> >>
> >>
> >> On Mon, Mar 14, 2016 at 1:29 PM, Jesse <pu...@gmail.com> wrote:
> >>> Considering all of the points previously mentioned, I would like to
> make a
> >>> supplementary proposal.
> >>>
> >>> We seem to all agree that platform rm+add is ideal in a world where we
> can
> >>> truly consider platforms as artifacts, but we are really not there yet.
> >>> The zipped snapshot of the platform before the update that Carlos
> mentions
> >>> is a good non-destructive way of allowing a developer the chance to
> always
> >>> go back.
> >>> I would like to take this approach one step further and suggest:
> >>> (note: I am using 'ios' as the example platform, but this applies to
> >>> any/all platforms )
> >>>
> >>> 1. when updating a project, we rename the previous platforms/ios/ to
> >>> include the version it was, and leave it in the platforms folder.
> >>> ex. platforms/ios/ -> platforms/ios@4.0.1/
> >>>
> >>> 2. platforms/ios would always contain the latest ios version installed
> for
> >>> this project. This would allow most tooling to work unchanged, and
> >>> sidesteps symlink issues on windows with things like ios-latest ->
> ios@4.02
> >>>
> >>> 3. [optional or stretch goal] 'platform rm ios' could be used to go
> back to
> >>> the previous 'current' version ( according to semver ) or should this
> be a
> >>> new command? like 'cordova platform pop ios' ?
> >>>
> >>> 4. we can add a flag to platform update ios --kill to do a destructive
> >>> update for users who know that that is what they want.
> >>>
> >>> 5. [optional | stretch ] allow build/run of platform artifacts as
> well, so
> >>> developers can run commands like : 'cordova run ios@4.0.1'
> >>>
> >>> 6. the platform listed in config.xml would always be the latest one,
> >>> regardless of how many artifacts were still around.
> >>>
> >>> Thoughts? Issues? Comments?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> @purplecabbage
> >>>
> https://na01.safelinks.protection.outlook.com/?url=risingj.com&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AYCfungKQfswLZClqFCBX2oacLlJixX8xOGAFiJjJcQ%3d
> >>>
> >>> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <da...@cellartracker.com>
> wrote:
> >>>
> >>>> As a user of cordova (and list lurker), I thought I'd chime in and say
> >>>> Carlos hit on some very good points. In theory I like the idea of
> treating
> >>>> platforms like build artifacts, but in reality -- at least for my
> current
> >>>> usage -- things are far from that. Making this type of change will
> make my
> >>>> upgrades more challenging. I'm willing to live with that, but PLEASE
> make
> >>>> sure you do a backup (or tell the user to) "just in case" before
> nuking
> >>>> their directory.
> >>>>
> >>>> Right now, I find I do more native (non CLI) development on iOS
> compared
> >>>> to other platforms. I'd have to do a full inventory of all of my
> native
> >>>> customizations, but as Carlos mentions it is a combination of:
> >>>>
> >>>> - working around bugs/limitations in the tools
> >>>> - additional AppDelegate customizations for native analytics
> libraries and
> >>>> error handling as our app is remotely hosted
> >>>> - the addition of dependencies as cocoapods
> >>>> - other build/plist customizations which are far simpler to modify
> >>>> directly, e.g. adding an entitlements file to support universal
> links, or
> >>>> adding ITSEncryptionExportComplianceCode to the plist to simplify app
> >>>> submissions
> >>>>
> >>>> Anyway, please just keep in mind those of us who may be doing things
> the
> >>>> "old way" as you move forward here.
> >>>>
> >>>> Dan
> >>>>
> >>>> -----Original Message-----
> >>>> From: Carlos Santana [mailto:csantana23@gmail.com]
> >>>> Sent: Tuesday, March 08, 2016 3:16 PM
> >>>> To: dev@cordova.apache.org
> >>>> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
> >>>> cordova-ios
> >>>>
> >>>> I was never a fan of the "platform update" command since it was not
> fully
> >>>> tested across the board.
> >>>> like all the permutations possible to/from upgrade. meaning going for
> very
> >>>> old like 3.6 to 5.1
> >>>>
> >>>> If we do this I think it will break a lot of people that got used to
> >>>> changing files inside platform/ios/ in terms of changing XCode
> settings in
> >>>> pbxproj like:
> >>>> - use story board to launch app to be able to support ipad pro
> >>>> - some initialization code in AppDelegate
> >>>> - Any native code they added like NativeUI to mix web and native
> >>>> - Changes to StoryBoard to adjust webview inside native view
> >>>> - Build and Signing settings in project or target in XCode
> >>>> - Installation of cocoapods
> >>>> - Xcode Build phases scripts
> >>>>
> >>>> Meaning that they will need to restore or generate all this things
> with
> >>>> hooks or plugins.
> >>>>
> >>>> I know that Darryl Pogue and Tommy have projects where they can
> >>>> successfully treat platfforms folder as 100% build artifact that they
> can
> >>>> throw away. But to get there is not super easy
> >>>>
> >>>> "platform update ios" has being scoped to only touch the CordovaLib
> xcode
> >>>> project, leaving the app xcode project not touched that's why it's
> being
> >>>> safe all along
> >>>>
> >>>> What was the root cause of the recent problems with 4.1.0 for update?
> >>>>
> >>>> Maybe we can restrict update command to major version, meaning going
> from
> >>>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
> >>>>
> >>>> In the current release of the IBM MobileFirst, were we have a CLI to
> wrap
> >>>> cordova commands we had a "$ mfp cordova platform update"
> >>>> We took a backup of the platform folder and create a zip with a
> timestamp
> >>>> (like ios_1457477724404.zip)
> >>>> We did this just in case the command was destructive and user didn't
> lost
> >>>> files just in case they didn't have all files checked-in/backup
> >>>>
> >>>> So doing a backup would be good if we move forward with this
> destructive
> >>>> action of doing a platform remove
> >>>>
> >>>>
> >>>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <by...@intel.com>
> wrote:
> >>>>
> >>>> > I second that. +1
> >>>> >
> >>>> > Byoungro So
> >>>> > SSG / DPD / Mobile Computing and Compilers
> >>>> > Intel Corporation
> >>>> >
> >>>> > From: Anis KADRI <anis.kadri@gmail.com<mailto:anis.kadri@gmail.com
> >>
> >>>> > Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> >>>> > Date: Tuesday, March 8, 2016 at 2:34 PM
> >>>> > To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> >>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> >>>> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add
> in
> >>>> > cordova-ios
> >>>> >
> >>>> > I support this as well. Real updates never work. Better to
> remove/add.
> >>>> >
> >>>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <stevengill97@gmail.com
> >>>> > <ma...@gmail.com>> wrote:
> >>>> >
> >>>> > I would also like to see this happen. Would this cause problems if
> we did
> >>>> > this for other platforms?
> >>>> >
> >>>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com<mailto:
> >>>> > shazron@gmail.com>> wrote:
> >>>> >
> >>>> > > See:
> >>>> > >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
> >>>> > >
> >>>> > > Problem:
> >>>> > > For cordova-ios, "cordova platform update" does its own thing,
> which
> >>>> > > causes problems.
> >>>> > >
> >>>> > > Proposal:
> >>>> > > Change "cordova platform update ios@version" to be basically an
> alias
> >>>> > for:
> >>>> > > "cordova platform rm ios"
> >>>> > > "cordova platform add ios@version"
> >>>> > >
> >>>> > >
> ---------------------------------------------------------------------
> >>>> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> <mailto:
> >>>> > dev-unsubscribe@cordova.apache.org>
> >>>> > > For additional commands, e-mail: dev-help@cordova.apache.org
> <mailto:
> >>>> > dev-help@cordova.apache.org>
> >>>> > >
> >>>> > >
> >>>> >
> >>>> >
> >>>> >
> >>>> >
> ---------------------------------------------------------------------
> >>>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>> > For additional commands, e-mail: dev-help@cordova.apache.org
> >>>> >
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
cordova-ios
Posted by Parashuram N <pa...@microsoft.com>.
Instead of adding an entire flag to remove previous versions, does it make sense to have cordova platform android@oldVersion. Alternatively, users could simple use the terminal to delete older versions from the command line inside the platform folders.
If we have users asking for a way to “remove all older platforms”, we could then introduce this flag.
On 3/14/16, 2:07 PM, "Shazron" <sh...@gmail.com> wrote:
>Note:
>I prefer `--remove-previous-versions` to `--kill` so as to be
>unambiguous and explicit.
>
>On Mon, Mar 14, 2016 at 2:01 PM, Shazron <sh...@gmail.com> wrote:
>> +1 I like it (esp reasons in #2)
>>
>> I agree that platform rm+add is not there yet, case in point all the
>> related issues in the "Issue Links" in this issue:
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
>>
>> Some comments:
>>
>> `cordova platform ls` should list these previous versions as well.
>>
>> `cordova platform add ios` should not delete these previous versions?
>>
>> `cordova platform update ios --kill` kills *all* previous versions,
>> regardless of major version (clarification)
>>
>> `cordova platform rm ios` should just remove the current version so it
>> doesn't get confusing. If we have listing of the previous versions
>> above in `cordova platform ls`, you would have to explicitly do a
>> `cordova platform rm ios@4.0.1` for example. However, this does not
>> solve for a way to remove *all* previous versions (we will have to
>> figure out a new command?)
>>
>>
>> On Mon, Mar 14, 2016 at 1:29 PM, Jesse <pu...@gmail.com> wrote:
>>> Considering all of the points previously mentioned, I would like to make a
>>> supplementary proposal.
>>>
>>> We seem to all agree that platform rm+add is ideal in a world where we can
>>> truly consider platforms as artifacts, but we are really not there yet.
>>> The zipped snapshot of the platform before the update that Carlos mentions
>>> is a good non-destructive way of allowing a developer the chance to always
>>> go back.
>>> I would like to take this approach one step further and suggest:
>>> (note: I am using 'ios' as the example platform, but this applies to
>>> any/all platforms )
>>>
>>> 1. when updating a project, we rename the previous platforms/ios/ to
>>> include the version it was, and leave it in the platforms folder.
>>> ex. platforms/ios/ -> platforms/ios@4.0.1/
>>>
>>> 2. platforms/ios would always contain the latest ios version installed for
>>> this project. This would allow most tooling to work unchanged, and
>>> sidesteps symlink issues on windows with things like ios-latest -> ios@4.02
>>>
>>> 3. [optional or stretch goal] 'platform rm ios' could be used to go back to
>>> the previous 'current' version ( according to semver ) or should this be a
>>> new command? like 'cordova platform pop ios' ?
>>>
>>> 4. we can add a flag to platform update ios --kill to do a destructive
>>> update for users who know that that is what they want.
>>>
>>> 5. [optional | stretch ] allow build/run of platform artifacts as well, so
>>> developers can run commands like : 'cordova run ios@4.0.1'
>>>
>>> 6. the platform listed in config.xml would always be the latest one,
>>> regardless of how many artifacts were still around.
>>>
>>> Thoughts? Issues? Comments?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> @purplecabbage
>>> https://na01.safelinks.protection.outlook.com/?url=risingj.com&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AYCfungKQfswLZClqFCBX2oacLlJixX8xOGAFiJjJcQ%3d
>>>
>>> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <da...@cellartracker.com> wrote:
>>>
>>>> As a user of cordova (and list lurker), I thought I'd chime in and say
>>>> Carlos hit on some very good points. In theory I like the idea of treating
>>>> platforms like build artifacts, but in reality -- at least for my current
>>>> usage -- things are far from that. Making this type of change will make my
>>>> upgrades more challenging. I'm willing to live with that, but PLEASE make
>>>> sure you do a backup (or tell the user to) "just in case" before nuking
>>>> their directory.
>>>>
>>>> Right now, I find I do more native (non CLI) development on iOS compared
>>>> to other platforms. I'd have to do a full inventory of all of my native
>>>> customizations, but as Carlos mentions it is a combination of:
>>>>
>>>> - working around bugs/limitations in the tools
>>>> - additional AppDelegate customizations for native analytics libraries and
>>>> error handling as our app is remotely hosted
>>>> - the addition of dependencies as cocoapods
>>>> - other build/plist customizations which are far simpler to modify
>>>> directly, e.g. adding an entitlements file to support universal links, or
>>>> adding ITSEncryptionExportComplianceCode to the plist to simplify app
>>>> submissions
>>>>
>>>> Anyway, please just keep in mind those of us who may be doing things the
>>>> "old way" as you move forward here.
>>>>
>>>> Dan
>>>>
>>>> -----Original Message-----
>>>> From: Carlos Santana [mailto:csantana23@gmail.com]
>>>> Sent: Tuesday, March 08, 2016 3:16 PM
>>>> To: dev@cordova.apache.org
>>>> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
>>>> cordova-ios
>>>>
>>>> I was never a fan of the "platform update" command since it was not fully
>>>> tested across the board.
>>>> like all the permutations possible to/from upgrade. meaning going for very
>>>> old like 3.6 to 5.1
>>>>
>>>> If we do this I think it will break a lot of people that got used to
>>>> changing files inside platform/ios/ in terms of changing XCode settings in
>>>> pbxproj like:
>>>> - use story board to launch app to be able to support ipad pro
>>>> - some initialization code in AppDelegate
>>>> - Any native code they added like NativeUI to mix web and native
>>>> - Changes to StoryBoard to adjust webview inside native view
>>>> - Build and Signing settings in project or target in XCode
>>>> - Installation of cocoapods
>>>> - Xcode Build phases scripts
>>>>
>>>> Meaning that they will need to restore or generate all this things with
>>>> hooks or plugins.
>>>>
>>>> I know that Darryl Pogue and Tommy have projects where they can
>>>> successfully treat platfforms folder as 100% build artifact that they can
>>>> throw away. But to get there is not super easy
>>>>
>>>> "platform update ios" has being scoped to only touch the CordovaLib xcode
>>>> project, leaving the app xcode project not touched that's why it's being
>>>> safe all along
>>>>
>>>> What was the root cause of the recent problems with 4.1.0 for update?
>>>>
>>>> Maybe we can restrict update command to major version, meaning going from
>>>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
>>>>
>>>> In the current release of the IBM MobileFirst, were we have a CLI to wrap
>>>> cordova commands we had a "$ mfp cordova platform update"
>>>> We took a backup of the platform folder and create a zip with a timestamp
>>>> (like ios_1457477724404.zip)
>>>> We did this just in case the command was destructive and user didn't lost
>>>> files just in case they didn't have all files checked-in/backup
>>>>
>>>> So doing a backup would be good if we move forward with this destructive
>>>> action of doing a platform remove
>>>>
>>>>
>>>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <by...@intel.com> wrote:
>>>>
>>>> > I second that. +1
>>>> >
>>>> > Byoungro So
>>>> > SSG / DPD / Mobile Computing and Compilers
>>>> > Intel Corporation
>>>> >
>>>> > From: Anis KADRI <an...@gmail.com>>
>>>> > Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
>>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>>>> > Date: Tuesday, March 8, 2016 at 2:34 PM
>>>> > To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
>>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>>>> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
>>>> > cordova-ios
>>>> >
>>>> > I support this as well. Real updates never work. Better to remove/add.
>>>> >
>>>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <stevengill97@gmail.com
>>>> > <ma...@gmail.com>> wrote:
>>>> >
>>>> > I would also like to see this happen. Would this cause problems if we did
>>>> > this for other platforms?
>>>> >
>>>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com<mailto:
>>>> > shazron@gmail.com>> wrote:
>>>> >
>>>> > > See:
>>>> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cpanarasi%40microsoft.com%7c224926aef1e64b5a937008d34c4cc8af%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1VmIoBecXUp3dVIMCsRB2dy7PzdHzpvHH0CgXu05Nyc%3d
>>>> > >
>>>> > > Problem:
>>>> > > For cordova-ios, "cordova platform update" does its own thing, which
>>>> > > causes problems.
>>>> > >
>>>> > > Proposal:
>>>> > > Change "cordova platform update ios@version" to be basically an alias
>>>> > for:
>>>> > > "cordova platform rm ios"
>>>> > > "cordova platform add ios@version"
>>>> > >
>>>> > > ---------------------------------------------------------------------
>>>> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<mailto:
>>>> > dev-unsubscribe@cordova.apache.org>
>>>> > > For additional commands, e-mail: dev-help@cordova.apache.org<mailto:
>>>> > dev-help@cordova.apache.org>
>>>> > >
>>>> > >
>>>> >
>>>> >
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>> > For additional commands, e-mail: dev-help@cordova.apache.org
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>For additional commands, e-mail: dev-help@cordova.apache.org
>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Shazron <sh...@gmail.com>.
Note:
I prefer `--remove-previous-versions` to `--kill` so as to be
unambiguous and explicit.
On Mon, Mar 14, 2016 at 2:01 PM, Shazron <sh...@gmail.com> wrote:
> +1 I like it (esp reasons in #2)
>
> I agree that platform rm+add is not there yet, case in point all the
> related issues in the "Issue Links" in this issue:
> https://issues.apache.org/jira/browse/CB-10775
>
> Some comments:
>
> `cordova platform ls` should list these previous versions as well.
>
> `cordova platform add ios` should not delete these previous versions?
>
> `cordova platform update ios --kill` kills *all* previous versions,
> regardless of major version (clarification)
>
> `cordova platform rm ios` should just remove the current version so it
> doesn't get confusing. If we have listing of the previous versions
> above in `cordova platform ls`, you would have to explicitly do a
> `cordova platform rm ios@4.0.1` for example. However, this does not
> solve for a way to remove *all* previous versions (we will have to
> figure out a new command?)
>
>
> On Mon, Mar 14, 2016 at 1:29 PM, Jesse <pu...@gmail.com> wrote:
>> Considering all of the points previously mentioned, I would like to make a
>> supplementary proposal.
>>
>> We seem to all agree that platform rm+add is ideal in a world where we can
>> truly consider platforms as artifacts, but we are really not there yet.
>> The zipped snapshot of the platform before the update that Carlos mentions
>> is a good non-destructive way of allowing a developer the chance to always
>> go back.
>> I would like to take this approach one step further and suggest:
>> (note: I am using 'ios' as the example platform, but this applies to
>> any/all platforms )
>>
>> 1. when updating a project, we rename the previous platforms/ios/ to
>> include the version it was, and leave it in the platforms folder.
>> ex. platforms/ios/ -> platforms/ios@4.0.1/
>>
>> 2. platforms/ios would always contain the latest ios version installed for
>> this project. This would allow most tooling to work unchanged, and
>> sidesteps symlink issues on windows with things like ios-latest -> ios@4.02
>>
>> 3. [optional or stretch goal] 'platform rm ios' could be used to go back to
>> the previous 'current' version ( according to semver ) or should this be a
>> new command? like 'cordova platform pop ios' ?
>>
>> 4. we can add a flag to platform update ios --kill to do a destructive
>> update for users who know that that is what they want.
>>
>> 5. [optional | stretch ] allow build/run of platform artifacts as well, so
>> developers can run commands like : 'cordova run ios@4.0.1'
>>
>> 6. the platform listed in config.xml would always be the latest one,
>> regardless of how many artifacts were still around.
>>
>> Thoughts? Issues? Comments?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> @purplecabbage
>> risingj.com
>>
>> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <da...@cellartracker.com> wrote:
>>
>>> As a user of cordova (and list lurker), I thought I'd chime in and say
>>> Carlos hit on some very good points. In theory I like the idea of treating
>>> platforms like build artifacts, but in reality -- at least for my current
>>> usage -- things are far from that. Making this type of change will make my
>>> upgrades more challenging. I'm willing to live with that, but PLEASE make
>>> sure you do a backup (or tell the user to) "just in case" before nuking
>>> their directory.
>>>
>>> Right now, I find I do more native (non CLI) development on iOS compared
>>> to other platforms. I'd have to do a full inventory of all of my native
>>> customizations, but as Carlos mentions it is a combination of:
>>>
>>> - working around bugs/limitations in the tools
>>> - additional AppDelegate customizations for native analytics libraries and
>>> error handling as our app is remotely hosted
>>> - the addition of dependencies as cocoapods
>>> - other build/plist customizations which are far simpler to modify
>>> directly, e.g. adding an entitlements file to support universal links, or
>>> adding ITSEncryptionExportComplianceCode to the plist to simplify app
>>> submissions
>>>
>>> Anyway, please just keep in mind those of us who may be doing things the
>>> "old way" as you move forward here.
>>>
>>> Dan
>>>
>>> -----Original Message-----
>>> From: Carlos Santana [mailto:csantana23@gmail.com]
>>> Sent: Tuesday, March 08, 2016 3:16 PM
>>> To: dev@cordova.apache.org
>>> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
>>> cordova-ios
>>>
>>> I was never a fan of the "platform update" command since it was not fully
>>> tested across the board.
>>> like all the permutations possible to/from upgrade. meaning going for very
>>> old like 3.6 to 5.1
>>>
>>> If we do this I think it will break a lot of people that got used to
>>> changing files inside platform/ios/ in terms of changing XCode settings in
>>> pbxproj like:
>>> - use story board to launch app to be able to support ipad pro
>>> - some initialization code in AppDelegate
>>> - Any native code they added like NativeUI to mix web and native
>>> - Changes to StoryBoard to adjust webview inside native view
>>> - Build and Signing settings in project or target in XCode
>>> - Installation of cocoapods
>>> - Xcode Build phases scripts
>>>
>>> Meaning that they will need to restore or generate all this things with
>>> hooks or plugins.
>>>
>>> I know that Darryl Pogue and Tommy have projects where they can
>>> successfully treat platfforms folder as 100% build artifact that they can
>>> throw away. But to get there is not super easy
>>>
>>> "platform update ios" has being scoped to only touch the CordovaLib xcode
>>> project, leaving the app xcode project not touched that's why it's being
>>> safe all along
>>>
>>> What was the root cause of the recent problems with 4.1.0 for update?
>>>
>>> Maybe we can restrict update command to major version, meaning going from
>>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
>>>
>>> In the current release of the IBM MobileFirst, were we have a CLI to wrap
>>> cordova commands we had a "$ mfp cordova platform update"
>>> We took a backup of the platform folder and create a zip with a timestamp
>>> (like ios_1457477724404.zip)
>>> We did this just in case the command was destructive and user didn't lost
>>> files just in case they didn't have all files checked-in/backup
>>>
>>> So doing a backup would be good if we move forward with this destructive
>>> action of doing a platform remove
>>>
>>>
>>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <by...@intel.com> wrote:
>>>
>>> > I second that. +1
>>> >
>>> > Byoungro So
>>> > SSG / DPD / Mobile Computing and Compilers
>>> > Intel Corporation
>>> >
>>> > From: Anis KADRI <an...@gmail.com>>
>>> > Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>>> > Date: Tuesday, March 8, 2016 at 2:34 PM
>>> > To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
>>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>>> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
>>> > cordova-ios
>>> >
>>> > I support this as well. Real updates never work. Better to remove/add.
>>> >
>>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <stevengill97@gmail.com
>>> > <ma...@gmail.com>> wrote:
>>> >
>>> > I would also like to see this happen. Would this cause problems if we did
>>> > this for other platforms?
>>> >
>>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com<mailto:
>>> > shazron@gmail.com>> wrote:
>>> >
>>> > > See:
>>> > > https://issues.apache.org/jira/browse/CB-10775
>>> > >
>>> > > Problem:
>>> > > For cordova-ios, "cordova platform update" does its own thing, which
>>> > > causes problems.
>>> > >
>>> > > Proposal:
>>> > > Change "cordova platform update ios@version" to be basically an alias
>>> > for:
>>> > > "cordova platform rm ios"
>>> > > "cordova platform add ios@version"
>>> > >
>>> > > ---------------------------------------------------------------------
>>> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<mailto:
>>> > dev-unsubscribe@cordova.apache.org>
>>> > > For additional commands, e-mail: dev-help@cordova.apache.org<mailto:
>>> > dev-help@cordova.apache.org>
>>> > >
>>> > >
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> > For additional commands, e-mail: dev-help@cordova.apache.org
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Shazron <sh...@gmail.com>.
+1 I like it (esp reasons in #2)
I agree that platform rm+add is not there yet, case in point all the
related issues in the "Issue Links" in this issue:
https://issues.apache.org/jira/browse/CB-10775
Some comments:
`cordova platform ls` should list these previous versions as well.
`cordova platform add ios` should not delete these previous versions?
`cordova platform update ios --kill` kills *all* previous versions,
regardless of major version (clarification)
`cordova platform rm ios` should just remove the current version so it
doesn't get confusing. If we have listing of the previous versions
above in `cordova platform ls`, you would have to explicitly do a
`cordova platform rm ios@4.0.1` for example. However, this does not
solve for a way to remove *all* previous versions (we will have to
figure out a new command?)
On Mon, Mar 14, 2016 at 1:29 PM, Jesse <pu...@gmail.com> wrote:
> Considering all of the points previously mentioned, I would like to make a
> supplementary proposal.
>
> We seem to all agree that platform rm+add is ideal in a world where we can
> truly consider platforms as artifacts, but we are really not there yet.
> The zipped snapshot of the platform before the update that Carlos mentions
> is a good non-destructive way of allowing a developer the chance to always
> go back.
> I would like to take this approach one step further and suggest:
> (note: I am using 'ios' as the example platform, but this applies to
> any/all platforms )
>
> 1. when updating a project, we rename the previous platforms/ios/ to
> include the version it was, and leave it in the platforms folder.
> ex. platforms/ios/ -> platforms/ios@4.0.1/
>
> 2. platforms/ios would always contain the latest ios version installed for
> this project. This would allow most tooling to work unchanged, and
> sidesteps symlink issues on windows with things like ios-latest -> ios@4.02
>
> 3. [optional or stretch goal] 'platform rm ios' could be used to go back to
> the previous 'current' version ( according to semver ) or should this be a
> new command? like 'cordova platform pop ios' ?
>
> 4. we can add a flag to platform update ios --kill to do a destructive
> update for users who know that that is what they want.
>
> 5. [optional | stretch ] allow build/run of platform artifacts as well, so
> developers can run commands like : 'cordova run ios@4.0.1'
>
> 6. the platform listed in config.xml would always be the latest one,
> regardless of how many artifacts were still around.
>
> Thoughts? Issues? Comments?
>
>
>
>
>
>
>
>
>
>
> @purplecabbage
> risingj.com
>
> On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <da...@cellartracker.com> wrote:
>
>> As a user of cordova (and list lurker), I thought I'd chime in and say
>> Carlos hit on some very good points. In theory I like the idea of treating
>> platforms like build artifacts, but in reality -- at least for my current
>> usage -- things are far from that. Making this type of change will make my
>> upgrades more challenging. I'm willing to live with that, but PLEASE make
>> sure you do a backup (or tell the user to) "just in case" before nuking
>> their directory.
>>
>> Right now, I find I do more native (non CLI) development on iOS compared
>> to other platforms. I'd have to do a full inventory of all of my native
>> customizations, but as Carlos mentions it is a combination of:
>>
>> - working around bugs/limitations in the tools
>> - additional AppDelegate customizations for native analytics libraries and
>> error handling as our app is remotely hosted
>> - the addition of dependencies as cocoapods
>> - other build/plist customizations which are far simpler to modify
>> directly, e.g. adding an entitlements file to support universal links, or
>> adding ITSEncryptionExportComplianceCode to the plist to simplify app
>> submissions
>>
>> Anyway, please just keep in mind those of us who may be doing things the
>> "old way" as you move forward here.
>>
>> Dan
>>
>> -----Original Message-----
>> From: Carlos Santana [mailto:csantana23@gmail.com]
>> Sent: Tuesday, March 08, 2016 3:16 PM
>> To: dev@cordova.apache.org
>> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
>> cordova-ios
>>
>> I was never a fan of the "platform update" command since it was not fully
>> tested across the board.
>> like all the permutations possible to/from upgrade. meaning going for very
>> old like 3.6 to 5.1
>>
>> If we do this I think it will break a lot of people that got used to
>> changing files inside platform/ios/ in terms of changing XCode settings in
>> pbxproj like:
>> - use story board to launch app to be able to support ipad pro
>> - some initialization code in AppDelegate
>> - Any native code they added like NativeUI to mix web and native
>> - Changes to StoryBoard to adjust webview inside native view
>> - Build and Signing settings in project or target in XCode
>> - Installation of cocoapods
>> - Xcode Build phases scripts
>>
>> Meaning that they will need to restore or generate all this things with
>> hooks or plugins.
>>
>> I know that Darryl Pogue and Tommy have projects where they can
>> successfully treat platfforms folder as 100% build artifact that they can
>> throw away. But to get there is not super easy
>>
>> "platform update ios" has being scoped to only touch the CordovaLib xcode
>> project, leaving the app xcode project not touched that's why it's being
>> safe all along
>>
>> What was the root cause of the recent problems with 4.1.0 for update?
>>
>> Maybe we can restrict update command to major version, meaning going from
>> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
>>
>> In the current release of the IBM MobileFirst, were we have a CLI to wrap
>> cordova commands we had a "$ mfp cordova platform update"
>> We took a backup of the platform folder and create a zip with a timestamp
>> (like ios_1457477724404.zip)
>> We did this just in case the command was destructive and user didn't lost
>> files just in case they didn't have all files checked-in/backup
>>
>> So doing a backup would be good if we move forward with this destructive
>> action of doing a platform remove
>>
>>
>> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <by...@intel.com> wrote:
>>
>> > I second that. +1
>> >
>> > Byoungro So
>> > SSG / DPD / Mobile Computing and Compilers
>> > Intel Corporation
>> >
>> > From: Anis KADRI <an...@gmail.com>>
>> > Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>> > Date: Tuesday, March 8, 2016 at 2:34 PM
>> > To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
>> > dev@cordova.apache.org<ma...@cordova.apache.org>>
>> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
>> > cordova-ios
>> >
>> > I support this as well. Real updates never work. Better to remove/add.
>> >
>> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <stevengill97@gmail.com
>> > <ma...@gmail.com>> wrote:
>> >
>> > I would also like to see this happen. Would this cause problems if we did
>> > this for other platforms?
>> >
>> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com<mailto:
>> > shazron@gmail.com>> wrote:
>> >
>> > > See:
>> > > https://issues.apache.org/jira/browse/CB-10775
>> > >
>> > > Problem:
>> > > For cordova-ios, "cordova platform update" does its own thing, which
>> > > causes problems.
>> > >
>> > > Proposal:
>> > > Change "cordova platform update ios@version" to be basically an alias
>> > for:
>> > > "cordova platform rm ios"
>> > > "cordova platform add ios@version"
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<mailto:
>> > dev-unsubscribe@cordova.apache.org>
>> > > For additional commands, e-mail: dev-help@cordova.apache.org<mailto:
>> > dev-help@cordova.apache.org>
>> > >
>> > >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Jesse <pu...@gmail.com>.
Considering all of the points previously mentioned, I would like to make a
supplementary proposal.
We seem to all agree that platform rm+add is ideal in a world where we can
truly consider platforms as artifacts, but we are really not there yet.
The zipped snapshot of the platform before the update that Carlos mentions
is a good non-destructive way of allowing a developer the chance to always
go back.
I would like to take this approach one step further and suggest:
(note: I am using 'ios' as the example platform, but this applies to
any/all platforms )
1. when updating a project, we rename the previous platforms/ios/ to
include the version it was, and leave it in the platforms folder.
ex. platforms/ios/ -> platforms/ios@4.0.1/
2. platforms/ios would always contain the latest ios version installed for
this project. This would allow most tooling to work unchanged, and
sidesteps symlink issues on windows with things like ios-latest -> ios@4.02
3. [optional or stretch goal] 'platform rm ios' could be used to go back to
the previous 'current' version ( according to semver ) or should this be a
new command? like 'cordova platform pop ios' ?
4. we can add a flag to platform update ios --kill to do a destructive
update for users who know that that is what they want.
5. [optional | stretch ] allow build/run of platform artifacts as well, so
developers can run commands like : 'cordova run ios@4.0.1'
6. the platform listed in config.xml would always be the latest one,
regardless of how many artifacts were still around.
Thoughts? Issues? Comments?
@purplecabbage
risingj.com
On Wed, Mar 9, 2016 at 10:38 AM, Dan Polivy <da...@cellartracker.com> wrote:
> As a user of cordova (and list lurker), I thought I'd chime in and say
> Carlos hit on some very good points. In theory I like the idea of treating
> platforms like build artifacts, but in reality -- at least for my current
> usage -- things are far from that. Making this type of change will make my
> upgrades more challenging. I'm willing to live with that, but PLEASE make
> sure you do a backup (or tell the user to) "just in case" before nuking
> their directory.
>
> Right now, I find I do more native (non CLI) development on iOS compared
> to other platforms. I'd have to do a full inventory of all of my native
> customizations, but as Carlos mentions it is a combination of:
>
> - working around bugs/limitations in the tools
> - additional AppDelegate customizations for native analytics libraries and
> error handling as our app is remotely hosted
> - the addition of dependencies as cocoapods
> - other build/plist customizations which are far simpler to modify
> directly, e.g. adding an entitlements file to support universal links, or
> adding ITSEncryptionExportComplianceCode to the plist to simplify app
> submissions
>
> Anyway, please just keep in mind those of us who may be doing things the
> "old way" as you move forward here.
>
> Dan
>
> -----Original Message-----
> From: Carlos Santana [mailto:csantana23@gmail.com]
> Sent: Tuesday, March 08, 2016 3:16 PM
> To: dev@cordova.apache.org
> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
> cordova-ios
>
> I was never a fan of the "platform update" command since it was not fully
> tested across the board.
> like all the permutations possible to/from upgrade. meaning going for very
> old like 3.6 to 5.1
>
> If we do this I think it will break a lot of people that got used to
> changing files inside platform/ios/ in terms of changing XCode settings in
> pbxproj like:
> - use story board to launch app to be able to support ipad pro
> - some initialization code in AppDelegate
> - Any native code they added like NativeUI to mix web and native
> - Changes to StoryBoard to adjust webview inside native view
> - Build and Signing settings in project or target in XCode
> - Installation of cocoapods
> - Xcode Build phases scripts
>
> Meaning that they will need to restore or generate all this things with
> hooks or plugins.
>
> I know that Darryl Pogue and Tommy have projects where they can
> successfully treat platfforms folder as 100% build artifact that they can
> throw away. But to get there is not super easy
>
> "platform update ios" has being scoped to only touch the CordovaLib xcode
> project, leaving the app xcode project not touched that's why it's being
> safe all along
>
> What was the root cause of the recent problems with 4.1.0 for update?
>
> Maybe we can restrict update command to major version, meaning going from
> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
>
> In the current release of the IBM MobileFirst, were we have a CLI to wrap
> cordova commands we had a "$ mfp cordova platform update"
> We took a backup of the platform folder and create a zip with a timestamp
> (like ios_1457477724404.zip)
> We did this just in case the command was destructive and user didn't lost
> files just in case they didn't have all files checked-in/backup
>
> So doing a backup would be good if we move forward with this destructive
> action of doing a platform remove
>
>
> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <by...@intel.com> wrote:
>
> > I second that. +1
> >
> > Byoungro So
> > SSG / DPD / Mobile Computing and Compilers
> > Intel Corporation
> >
> > From: Anis KADRI <an...@gmail.com>>
> > Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> > Date: Tuesday, March 8, 2016 at 2:34 PM
> > To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
> > cordova-ios
> >
> > I support this as well. Real updates never work. Better to remove/add.
> >
> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <stevengill97@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > I would also like to see this happen. Would this cause problems if we did
> > this for other platforms?
> >
> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com<mailto:
> > shazron@gmail.com>> wrote:
> >
> > > See:
> > > https://issues.apache.org/jira/browse/CB-10775
> > >
> > > Problem:
> > > For cordova-ios, "cordova platform update" does its own thing, which
> > > causes problems.
> > >
> > > Proposal:
> > > Change "cordova platform update ios@version" to be basically an alias
> > for:
> > > "cordova platform rm ios"
> > > "cordova platform add ios@version"
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<mailto:
> > dev-unsubscribe@cordova.apache.org>
> > > For additional commands, e-mail: dev-help@cordova.apache.org<mailto:
> > dev-help@cordova.apache.org>
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
RE: [PROPOSAL] 'cordova platform update' alias for rm, add in
cordova-ios
Posted by Dan Polivy <da...@cellartracker.com>.
As a user of cordova (and list lurker), I thought I'd chime in and say Carlos hit on some very good points. In theory I like the idea of treating platforms like build artifacts, but in reality -- at least for my current usage -- things are far from that. Making this type of change will make my upgrades more challenging. I'm willing to live with that, but PLEASE make sure you do a backup (or tell the user to) "just in case" before nuking their directory.
Right now, I find I do more native (non CLI) development on iOS compared to other platforms. I'd have to do a full inventory of all of my native customizations, but as Carlos mentions it is a combination of:
- working around bugs/limitations in the tools
- additional AppDelegate customizations for native analytics libraries and error handling as our app is remotely hosted
- the addition of dependencies as cocoapods
- other build/plist customizations which are far simpler to modify directly, e.g. adding an entitlements file to support universal links, or adding ITSEncryptionExportComplianceCode to the plist to simplify app submissions
Anyway, please just keep in mind those of us who may be doing things the "old way" as you move forward here.
Dan
-----Original Message-----
From: Carlos Santana [mailto:csantana23@gmail.com]
Sent: Tuesday, March 08, 2016 3:16 PM
To: dev@cordova.apache.org
Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
I was never a fan of the "platform update" command since it was not fully
tested across the board.
like all the permutations possible to/from upgrade. meaning going for very
old like 3.6 to 5.1
If we do this I think it will break a lot of people that got used to
changing files inside platform/ios/ in terms of changing XCode settings in
pbxproj like:
- use story board to launch app to be able to support ipad pro
- some initialization code in AppDelegate
- Any native code they added like NativeUI to mix web and native
- Changes to StoryBoard to adjust webview inside native view
- Build and Signing settings in project or target in XCode
- Installation of cocoapods
- Xcode Build phases scripts
Meaning that they will need to restore or generate all this things with
hooks or plugins.
I know that Darryl Pogue and Tommy have projects where they can
successfully treat platfforms folder as 100% build artifact that they can
throw away. But to get there is not super easy
"platform update ios" has being scoped to only touch the CordovaLib xcode
project, leaving the app xcode project not touched that's why it's being
safe all along
What was the root cause of the recent problems with 4.1.0 for update?
Maybe we can restrict update command to major version, meaning going from
4.x to 4.x is OK but from 3.x to 4.x is not OK.
In the current release of the IBM MobileFirst, were we have a CLI to wrap
cordova commands we had a "$ mfp cordova platform update"
We took a backup of the platform folder and create a zip with a timestamp
(like ios_1457477724404.zip)
We did this just in case the command was destructive and user didn't lost
files just in case they didn't have all files checked-in/backup
So doing a backup would be good if we move forward with this destructive
action of doing a platform remove
On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <by...@intel.com> wrote:
> I second that. +1
>
> Byoungro So
> SSG / DPD / Mobile Computing and Compilers
> Intel Corporation
>
> From: Anis KADRI <an...@gmail.com>>
> Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> dev@cordova.apache.org<ma...@cordova.apache.org>>
> Date: Tuesday, March 8, 2016 at 2:34 PM
> To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> dev@cordova.apache.org<ma...@cordova.apache.org>>
> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
> cordova-ios
>
> I support this as well. Real updates never work. Better to remove/add.
>
> On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <stevengill97@gmail.com
> <ma...@gmail.com>> wrote:
>
> I would also like to see this happen. Would this cause problems if we did
> this for other platforms?
>
> On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com<mailto:
> shazron@gmail.com>> wrote:
>
> > See:
> > https://issues.apache.org/jira/browse/CB-10775
> >
> > Problem:
> > For cordova-ios, "cordova platform update" does its own thing, which
> > causes problems.
> >
> > Proposal:
> > Change "cordova platform update ios@version" to be basically an alias
> for:
> > "cordova platform rm ios"
> > "cordova platform add ios@version"
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<mailto:
> dev-unsubscribe@cordova.apache.org>
> > For additional commands, e-mail: dev-help@cordova.apache.org<mailto:
> dev-help@cordova.apache.org>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Carlos Santana <cs...@gmail.com>.
I agree having an "override" folder is a good start towards that goal
In IBM MobileFirst hybrid apps also have similar feature, they don't have a
cordova 3.x directory structure but in concept is similar
android/native/Resources/
blackberry/native/Resources/
I would not use the folder name "Resources" but do it similar as merges
today we have web overrides with:
merges/<platform> get's copied to the platform's www
maybe we can keep same concept and under "merges" folder by adding a
"native" folder
merges/native/<platform>
any files get's copied to cordovaproject/platforms/<platform>/
or be at the root of the cordova project, but you get the picture :-)
native/<platform>
this will be just a simple copy file system based, not adding native
resources into ios xcode bundle, that could be implemented on top/later
On Wed, Mar 9, 2016 at 1:01 PM Nikhil Khandelwal <ni...@microsoft.com>
wrote:
> In Visual Studio, we have a feature similar to "merges" to allow users to
> override content of platform folder. We use hooks to copy the contents of
> the folder to the platforms directory. Other than that VS does consider
> platforms/ directory a build artifact and often ends up deleting it on
> behalf of the user - especially when cordova CLI version is changed.
>
> Perhaps we can add a similar feature to cordova CLI, to allow overrides of
> certain files and move to having platforms/ as a true build artifact.
>
> Thanks,
> Nikhil
>
> -----Original Message-----
> From: Carlos Santana [mailto:csantana23@gmail.com]
> Sent: Tuesday, March 8, 2016 3:16 PM
> To: dev@cordova.apache.org
> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
> cordova-ios
>
> I was never a fan of the "platform update" command since it was not fully
> tested across the board.
> like all the permutations possible to/from upgrade. meaning going for very
> old like 3.6 to 5.1
>
> If we do this I think it will break a lot of people that got used to
> changing files inside platform/ios/ in terms of changing XCode settings in
> pbxproj like:
> - use story board to launch app to be able to support ipad pro
> - some initialization code in AppDelegate
> - Any native code they added like NativeUI to mix web and native
> - Changes to StoryBoard to adjust webview inside native view
> - Build and Signing settings in project or target in XCode
> - Installation of cocoapods
> - Xcode Build phases scripts
>
> Meaning that they will need to restore or generate all this things with
> hooks or plugins.
>
> I know that Darryl Pogue and Tommy have projects where they can
> successfully treat platfforms folder as 100% build artifact that they can
> throw away. But to get there is not super easy
>
> "platform update ios" has being scoped to only touch the CordovaLib xcode
> project, leaving the app xcode project not touched that's why it's being
> safe all along
>
> What was the root cause of the recent problems with 4.1.0 for update?
>
> Maybe we can restrict update command to major version, meaning going from
> 4.x to 4.x is OK but from 3.x to 4.x is not OK.
>
> In the current release of the IBM MobileFirst, were we have a CLI to wrap
> cordova commands we had a "$ mfp cordova platform update"
> We took a backup of the platform folder and create a zip with a timestamp
> (like ios_1457477724404.zip) We did this just in case the command was
> destructive and user didn't lost files just in case they didn't have all
> files checked-in/backup
>
> So doing a backup would be good if we move forward with this destructive
> action of doing a platform remove
>
>
> On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <by...@intel.com> wrote:
>
> > I second that. +1
> >
> > Byoungro So
> > SSG / DPD / Mobile Computing and Compilers Intel Corporation
> >
> > From: Anis KADRI <an...@gmail.com>>
> > Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> > Date: Tuesday, March 8, 2016 at 2:34 PM
> > To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> > dev@cordova.apache.org<ma...@cordova.apache.org>>
> > Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
> > cordova-ios
> >
> > I support this as well. Real updates never work. Better to remove/add.
> >
> > On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <stevengill97@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > I would also like to see this happen. Would this cause problems if we
> > did this for other platforms?
> >
> > On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com<mailto:
> > shazron@gmail.com>> wrote:
> >
> > > See:
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fiss
> > > ues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cnikhilkh%40
> > > microsoft.com%7c0f81ee3188ce4f6de3cf08d347a797a4%7c72f988bf86f141af9
> > > 1ab2d7cd011db47%7c1&sdata=Yn8Lqnh4gBDOe5996%2bQKvpZfI308xq%2fO73BUD1
> > > U%2b7xI%3d
> > >
> > > Problem:
> > > For cordova-ios, "cordova platform update" does its own thing, which
> > > causes problems.
> > >
> > > Proposal:
> > > Change "cordova platform update ios@version" to be basically an
> > > alias
> > for:
> > > "cordova platform rm ios"
> > > "cordova platform add ios@version"
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<mailto:
> > dev-unsubscribe@cordova.apache.org>
> > > For additional commands, e-mail: dev-help@cordova.apache.org<mailto:
> > dev-help@cordova.apache.org>
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
RE: [PROPOSAL] 'cordova platform update' alias for rm, add in
cordova-ios
Posted by Nikhil Khandelwal <ni...@microsoft.com>.
In Visual Studio, we have a feature similar to "merges" to allow users to override content of platform folder. We use hooks to copy the contents of the folder to the platforms directory. Other than that VS does consider platforms/ directory a build artifact and often ends up deleting it on behalf of the user - especially when cordova CLI version is changed.
Perhaps we can add a similar feature to cordova CLI, to allow overrides of certain files and move to having platforms/ as a true build artifact.
Thanks,
Nikhil
-----Original Message-----
From: Carlos Santana [mailto:csantana23@gmail.com]
Sent: Tuesday, March 8, 2016 3:16 PM
To: dev@cordova.apache.org
Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
I was never a fan of the "platform update" command since it was not fully tested across the board.
like all the permutations possible to/from upgrade. meaning going for very old like 3.6 to 5.1
If we do this I think it will break a lot of people that got used to changing files inside platform/ios/ in terms of changing XCode settings in pbxproj like:
- use story board to launch app to be able to support ipad pro
- some initialization code in AppDelegate
- Any native code they added like NativeUI to mix web and native
- Changes to StoryBoard to adjust webview inside native view
- Build and Signing settings in project or target in XCode
- Installation of cocoapods
- Xcode Build phases scripts
Meaning that they will need to restore or generate all this things with hooks or plugins.
I know that Darryl Pogue and Tommy have projects where they can successfully treat platfforms folder as 100% build artifact that they can throw away. But to get there is not super easy
"platform update ios" has being scoped to only touch the CordovaLib xcode project, leaving the app xcode project not touched that's why it's being safe all along
What was the root cause of the recent problems with 4.1.0 for update?
Maybe we can restrict update command to major version, meaning going from 4.x to 4.x is OK but from 3.x to 4.x is not OK.
In the current release of the IBM MobileFirst, were we have a CLI to wrap cordova commands we had a "$ mfp cordova platform update"
We took a backup of the platform folder and create a zip with a timestamp (like ios_1457477724404.zip) We did this just in case the command was destructive and user didn't lost files just in case they didn't have all files checked-in/backup
So doing a backup would be good if we move forward with this destructive action of doing a platform remove
On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <by...@intel.com> wrote:
> I second that. +1
>
> Byoungro So
> SSG / DPD / Mobile Computing and Compilers Intel Corporation
>
> From: Anis KADRI <an...@gmail.com>>
> Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> dev@cordova.apache.org<ma...@cordova.apache.org>>
> Date: Tuesday, March 8, 2016 at 2:34 PM
> To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> dev@cordova.apache.org<ma...@cordova.apache.org>>
> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
> cordova-ios
>
> I support this as well. Real updates never work. Better to remove/add.
>
> On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <stevengill97@gmail.com
> <ma...@gmail.com>> wrote:
>
> I would also like to see this happen. Would this cause problems if we
> did this for other platforms?
>
> On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com<mailto:
> shazron@gmail.com>> wrote:
>
> > See:
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fiss
> > ues.apache.org%2fjira%2fbrowse%2fCB-10775&data=01%7c01%7cnikhilkh%40
> > microsoft.com%7c0f81ee3188ce4f6de3cf08d347a797a4%7c72f988bf86f141af9
> > 1ab2d7cd011db47%7c1&sdata=Yn8Lqnh4gBDOe5996%2bQKvpZfI308xq%2fO73BUD1
> > U%2b7xI%3d
> >
> > Problem:
> > For cordova-ios, "cordova platform update" does its own thing, which
> > causes problems.
> >
> > Proposal:
> > Change "cordova platform update ios@version" to be basically an
> > alias
> for:
> > "cordova platform rm ios"
> > "cordova platform add ios@version"
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<mailto:
> dev-unsubscribe@cordova.apache.org>
> > For additional commands, e-mail: dev-help@cordova.apache.org<mailto:
> dev-help@cordova.apache.org>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Carlos Santana <cs...@gmail.com>.
I was never a fan of the "platform update" command since it was not fully
tested across the board.
like all the permutations possible to/from upgrade. meaning going for very
old like 3.6 to 5.1
If we do this I think it will break a lot of people that got used to
changing files inside platform/ios/ in terms of changing XCode settings in
pbxproj like:
- use story board to launch app to be able to support ipad pro
- some initialization code in AppDelegate
- Any native code they added like NativeUI to mix web and native
- Changes to StoryBoard to adjust webview inside native view
- Build and Signing settings in project or target in XCode
- Installation of cocoapods
- Xcode Build phases scripts
Meaning that they will need to restore or generate all this things with
hooks or plugins.
I know that Darryl Pogue and Tommy have projects where they can
successfully treat platfforms folder as 100% build artifact that they can
throw away. But to get there is not super easy
"platform update ios" has being scoped to only touch the CordovaLib xcode
project, leaving the app xcode project not touched that's why it's being
safe all along
What was the root cause of the recent problems with 4.1.0 for update?
Maybe we can restrict update command to major version, meaning going from
4.x to 4.x is OK but from 3.x to 4.x is not OK.
In the current release of the IBM MobileFirst, were we have a CLI to wrap
cordova commands we had a "$ mfp cordova platform update"
We took a backup of the platform folder and create a zip with a timestamp
(like ios_1457477724404.zip)
We did this just in case the command was destructive and user didn't lost
files just in case they didn't have all files checked-in/backup
So doing a backup would be good if we move forward with this destructive
action of doing a platform remove
On Tue, Mar 8, 2016 at 5:36 PM So, Byoungro <by...@intel.com> wrote:
> I second that. +1
>
> Byoungro So
> SSG / DPD / Mobile Computing and Compilers
> Intel Corporation
>
> From: Anis KADRI <an...@gmail.com>>
> Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> dev@cordova.apache.org<ma...@cordova.apache.org>>
> Date: Tuesday, March 8, 2016 at 2:34 PM
> To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <
> dev@cordova.apache.org<ma...@cordova.apache.org>>
> Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
> cordova-ios
>
> I support this as well. Real updates never work. Better to remove/add.
>
> On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <stevengill97@gmail.com
> <ma...@gmail.com>> wrote:
>
> I would also like to see this happen. Would this cause problems if we did
> this for other platforms?
>
> On Tue, Mar 8, 2016 at 11:55 AM, Shazron <shazron@gmail.com<mailto:
> shazron@gmail.com>> wrote:
>
> > See:
> > https://issues.apache.org/jira/browse/CB-10775
> >
> > Problem:
> > For cordova-ios, "cordova platform update" does its own thing, which
> > causes problems.
> >
> > Proposal:
> > Change "cordova platform update ios@version" to be basically an alias
> for:
> > "cordova platform rm ios"
> > "cordova platform add ios@version"
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<mailto:
> dev-unsubscribe@cordova.apache.org>
> > For additional commands, e-mail: dev-help@cordova.apache.org<mailto:
> dev-help@cordova.apache.org>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in
cordova-ios
Posted by "So, Byoungro" <by...@intel.com>.
I second that. +1
Byoungro So
SSG / DPD / Mobile Computing and Compilers
Intel Corporation
From: Anis KADRI <an...@gmail.com>>
Reply-To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <de...@cordova.apache.org>>
Date: Tuesday, March 8, 2016 at 2:34 PM
To: "dev@cordova.apache.org<ma...@cordova.apache.org>" <de...@cordova.apache.org>>
Subject: Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
I support this as well. Real updates never work. Better to remove/add.
On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <st...@gmail.com>> wrote:
I would also like to see this happen. Would this cause problems if we did
this for other platforms?
On Tue, Mar 8, 2016 at 11:55 AM, Shazron <sh...@gmail.com>> wrote:
> See:
> https://issues.apache.org/jira/browse/CB-10775
>
> Problem:
> For cordova-ios, "cordova platform update" does its own thing, which
> causes problems.
>
> Proposal:
> Change "cordova platform update ios@version" to be basically an alias
for:
> "cordova platform rm ios"
> "cordova platform add ios@version"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<ma...@cordova.apache.org>
> For additional commands, e-mail: dev-help@cordova.apache.org<ma...@cordova.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Anis KADRI <an...@gmail.com>.
I support this as well. Real updates never work. Better to remove/add.
On Tue, Mar 8, 2016 at 12:04 PM Steven Gill <st...@gmail.com> wrote:
> I would also like to see this happen. Would this cause problems if we did
> this for other platforms?
>
> On Tue, Mar 8, 2016 at 11:55 AM, Shazron <sh...@gmail.com> wrote:
>
> > See:
> > https://issues.apache.org/jira/browse/CB-10775
> >
> > Problem:
> > For cordova-ios, "cordova platform update" does its own thing, which
> > causes problems.
> >
> > Proposal:
> > Change "cordova platform update ios@version" to be basically an alias
> for:
> > "cordova platform rm ios"
> > "cordova platform add ios@version"
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>
Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Posted by Steven Gill <st...@gmail.com>.
I would also like to see this happen. Would this cause problems if we did
this for other platforms?
On Tue, Mar 8, 2016 at 11:55 AM, Shazron <sh...@gmail.com> wrote:
> See:
> https://issues.apache.org/jira/browse/CB-10775
>
> Problem:
> For cordova-ios, "cordova platform update" does its own thing, which
> causes problems.
>
> Proposal:
> Change "cordova platform update ios@version" to be basically an alias for:
> "cordova platform rm ios"
> "cordova platform add ios@version"
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>