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://issues.apache.org/jira/browse/CB-10775 > > 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 >> risingj.com >> >> 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://issues.apache.org/jira/browse/CB-10775 >>> > > >>> > > 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
