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 >