It would seem that the separation in that case should be between "what" and "how" -- make -lib responsible for "what" needs to be done (add an icon, add a splash screen, set the start page), and the platforms responsible for actually implementing it.
(Obviously easy to say; I'm sure there are a hundred things I haven't thought of. We could at least start by looking at the use cases: see what common things -lib is currently responsible for) On Fri, Sep 19, 2014 at 10:00 AM, Michal Mocny <mmo...@chromium.org> wrote: > Not sure about this. On the surface the request seems fine, but I think > its easier to do lib updates than platform updates, and the reverse problem > would happen if we made the switch: if we want to improve the way we do > parsing (say to add a new config option), we now have to do a full platform > release and get users to upgrade their projects. > > -Michal > > On Fri, Sep 19, 2014 at 9:27 AM, Sergey Grebnov (Akvelon) < > v-seg...@microsoft.com> wrote: > > > Hi, > > > > Currently LIB is on response for handling config.xml params and updating > > platforms, for example on Android[1] LIB edits AndroidManifest.xml as per > > config.xml, handles icons and splash images, etc. Moving forward with > > independed platform releases I see how it would be valuable to be able > add > > some changes to prepare logic with platform release. Another point of > > moving this logic to platforms is better decoupling of platform specific > > logic/code and shared functionality managed by LIB. > > > > So I propose to add 'prepare' script to the platforms similar to > > build/deploy so that LIB contains minimal required functionality and the > > rest of the logic is exposed by platform itself. > > > > Thoughts? > > > > [1] > > > https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/metadata/android_parser.js > > > > Thx! > > Sergey > > >
