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