+1 to Jesse’s new proposal. Looks like a nice idea and we don’t break existing tooling. We could symlink /platforms/ios to always point to latest, but that would not work on Windows. This is a better approach.
On 3/14/16, 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%7ce5118e6f28684a85e33a08d34c476c39%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=q8G%2fXrFtV4GigDIKa7s5cH8bZlfgrIwwjcxZtu3R1Xs%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%7ce5118e6f28684a85e33a08d34c476c39%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=pl3ikV3R7hGuGK5DrODaYDciW%2b47dE%2bUIxNUZyAUh4I%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 >>
