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 13:54:11 GMT
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" <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