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 <[email protected]> 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 -> [email protected] > 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 [email protected] > > 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 > [email protected] will simple delete /platforms/[email protected] > 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/[email protected] > add platforms/ios > .... > cordova migrate ios [email protected] > > This cli migrate command migrate helps user migrate things from 4.0.1 > ([email protected]) 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 <[email protected]> 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 <[email protected]> >> 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" <[email protected]> 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 <[email protected]> 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 [email protected]` 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 <[email protected]> >> 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/[email protected]/ >> > >>> >> > >>> 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 -> >> > [email protected] >> > >>> >> > >>> 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 [email protected]' >> > >>> >> > >>> 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 <[email protected]> >> > 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:[email protected]] >> > >>>> Sent: Tuesday, March 08, 2016 3:16 PM >> > >>>> To: [email protected] >> > >>>> 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 <[email protected] >> > >> > wrote: >> > >>>> >> > >>>> > I second that. +1 >> > >>>> > >> > >>>> > Byoungro So >> > >>>> > SSG / DPD / Mobile Computing and Compilers >> > >>>> > Intel Corporation >> > >>>> > >> > >>>> > From: Anis KADRI <[email protected]<mailto: >> [email protected] >> > >> >> > >>>> > Reply-To: "[email protected]<mailto:[email protected]>" >> < >> > >>>> > [email protected]<mailto:[email protected]>> >> > >>>> > Date: Tuesday, March 8, 2016 at 2:34 PM >> > >>>> > To: "[email protected]<mailto:[email protected]>" < >> > >>>> > [email protected]<mailto:[email protected]>> >> > >>>> > 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 < >> [email protected] >> > >>>> > <mailto:[email protected]>> 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 <[email protected] >> <mailto: >> > >>>> > [email protected]>> 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: [email protected] >> > <mailto: >> > >>>> > [email protected]> >> > >>>> > > For additional commands, e-mail: [email protected] >> > <mailto: >> > >>>> > [email protected]> >> > >>>> > > >> > >>>> > > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > --------------------------------------------------------------------- >> > >>>> > To unsubscribe, e-mail: [email protected] >> > >>>> > For additional commands, e-mail: [email protected] >> > >>>> > >> > >>>> >> > >>>> >> --------------------------------------------------------------------- >> > >>>> To unsubscribe, e-mail: [email protected] >> > >>>> For additional commands, e-mail: [email protected] >> > >>>> >> > > >> > >--------------------------------------------------------------------- >> > >To unsubscribe, e-mail: [email protected] >> > >For additional commands, e-mail: [email protected] >> > > >> > >> > >> >
