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 > > > > > > > >
