cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Parashuram N <panar...@microsoft.com>
Subject Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Date Mon, 14 Mar 2016 22:58:24 GMT
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" <shazron@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%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<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
>>>> > <mailto:stevengill97@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
>

Mime
View raw message