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 <csantan...@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 <csantan...@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 <purplecabb...@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 <panar...@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" <shaz...@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 <shaz...@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 <purplecabb...@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 <d...@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:csantan...@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...@intel.com> >>> > wrote: >>> > >>>> >>> > >>>> > I second that. +1 >>> > >>>> > >>> > >>>> > Byoungro So >>> > >>>> > SSG / DPD / Mobile Computing and Compilers >>> > >>>> > Intel Corporation >>> > >>>> > >>> > >>>> > From: Anis KADRI <anis.ka...@gmail.com<mailto: >>> anis.ka...@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 < >>> stevengil...@gmail.com >>> > >>>> > <mailto:stevengil...@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 <shaz...@gmail.com >>> <mailto: >>> > >>>> > shaz...@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-unsubscr...@cordova.apache.org >>> > <mailto: >>> > >>>> > dev-unsubscr...@cordova.apache.org> >>> > >>>> > > For additional commands, e-mail: dev-h...@cordova.apache.org >>> > <mailto: >>> > >>>> > dev-h...@cordova.apache.org> >>> > >>>> > > >>> > >>>> > > >>> > >>>> > >>> > >>>> > >>> > >>>> > >>> > >>>> > >>> > --------------------------------------------------------------------- >>> > >>>> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>> > >>>> > For additional commands, e-mail: dev-h...@cordova.apache.org >>> > >>>> > >>> > >>>> >>> > >>>> >>> --------------------------------------------------------------------- >>> > >>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>> > >>>> For additional commands, e-mail: dev-h...@cordova.apache.org >>> > >>>> >>> > > >>> > >--------------------------------------------------------------------- >>> > >To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>> > >For additional commands, e-mail: dev-h...@cordova.apache.org >>> > > >>> > >>> > >>> >>
