cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: [PROPOSAL] 'cordova platform update' alias for rm, add in cordova-ios
Date Wed, 16 Mar 2016 02:31:57 GMT
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" <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message