Michal, Yes. That would be a fairly common scenario for non-CLI users. I download a new Cordova version and migrate my app. In the development cycle, I may also want to have different versions of the same app. That could be because of different Cordova versions or even platform versions (iOS 6 vs iOS 7). Even using CLI, I am thinking I may still run multiple versions. Right now, mainly to keep a consistent version across the platforms & plug-ins. Maybe that will go away when we get the versioning strategy figured out.
-James Jong On Aug 28, 2013, at 5:09 PM, Michal Mocny <[email protected]> wrote: > James, > > I think that sounds like what we've been thinking -- but, why do you expect > to need to copy something when doing an upgrade? Is it because you think > upgrade means re-creating a new workspace (which is kinda true right now)? > We are hoping to support in-place upgrades, with no copies needed. > > -Michal > > > On Wed, Aug 28, 2013 at 4:34 PM, James Jong <[email protected]> wrote: > >> I think you have covered the common workflows. Some developers will have >> their own workflow but it should resemble the bin script method in the end. >> >> What I'd like to see is the ability to have my app's user config.xml (1 >> per platform would be fine) and have defaults for what is not specified >> there. The user specified config.xml takes precedence. So when I upgrade, >> I just need to copy over the config.xml. >> >> -James Jong >> >> On Aug 28, 2013, at 2:56 PM, Michal Mocny <[email protected]> wrote: >> >>> supporting platforms/ as generated content (aka "build artifact") is >>> certainly an ultimate goal, but only for the CLI workflow, and even then >> we >>> would love to suport fallback to sane actions when users don't see it >> that >>> way and do modify platforms/. >>> >>> Second, a single config.xml shared for all platforms, modified directly >> by >>> the user maybe might be possible (may involve <platform> tags or just >>> whitelisted tag per platform), but I'm not sure thats really what we >> want: >>> * Plugins modify it anyway, so its not really the final version >>> * When we upgrade platforms we may want to add/remove/change default >>> values, so its better to separate platform defaults from user explicit >>> choices >>> >>> -Michal >>> >>> On Wed, Aug 28, 2013 at 2:30 PM, Gorkem Ercan <[email protected] >>> wrote: >>> >>>> We (JBoss Tools) have been playing with ideas on how to work with >>>> config.xml. One thing we do right now is to have only one config.xml >> file, >>>> we try to treat config.xml as a universal way of defining cordova >>>> applications. We do not have platform versions of config,xml (l think >> cli >>>> massages them per platform right now) but rather copy the config.xml to >>>> platform directory (I guess on CLI this would be at the prepare stage) >> . I >>>> think what the developer works with and what gets deployed in the >>>> application should be same. It prevents any surprises to developer when >>>> he/she is trying to debug a problem. I guess use case/requirement here >> is >>>> not to have config.xml differences between platforms. >>>> >>>> As a note we treat platforms/... directory as generated content (and >>>> regenerate them when needed). >>>> -- >>>> Gorkem >>>> >>>> >>>> On Wed, Aug 28, 2013 at 1:49 PM, Braden Shepherdson < >> [email protected] >>>>> wrote: >>>> >>>>> So we have several bugs[1][2][3] about fixing the handling of >> config.xml >>>>> and of upgrading CLI projects. Upgrading platforms is hard because the >>>> user >>>>> might have been modifying files in the platforms/foo directory, and we >>>>> don't want to go overwriting them. Most of the time the file that's >> been >>>>> changed is the platform's config.xml. >>>>> >>>>> So we (the Google team) are working on a proposal for rearranging how >> we >>>>> handle config.xml files in order to make upgrades easier, and solving >>>> some >>>>> of these other problems (splash screens) easier. Also to make the CLI >>>>> tooling simpler, because currently the platform config.xml file is both >>>> the >>>>> input and output of several processes (mainly adding and removing >>>> plugins, >>>>> as well as cordova prepare). >>>>> >>>>> What we want to know, in writing this proposal is: what use-cases for >> the >>>>> config.xml files are there? There seem to be two: >>>>> 1. Not using CLI, just bin/create and maybe Plugman. >>>>> 2. Using CLI, and needing to upgrade smoothly from the 3.0 world to 3.1 >>>>> with these changes to the files. >>>>> >>>>> Is there anything else we should be thinking about? If not, we'll have >>>> the >>>>> proposal sent around tomorrow. >>>>> >>>>> >>>>> Braden >>>>> >>>>> [1] https://issues.apache.org/jira/browse/CB-4624 >>>>> [2] https://issues.apache.org/jira/browse/CB-3216 >>>>> [3] https://issues.apache.org/jira/browse/CB-3571 >>>>> >>>> >> >>
