I agree that moving plugins into repos isn't tied to API audits, but doesn't moving plugins gradually prevent our ability to do releases? E.g. 2.7 is missing two plugins since they were moved into different repos.
On Fri, Apr 5, 2013 at 4:20 PM, Brian LeRoux <b...@brian.io> wrote: > That synopsis on the wiki was super helpful Joe. I think we should stop > thinking we have to do EVERYTHING ALL AT ONCE. We do not need to audit any > apis. We do not need to update anything before moving into plugins. > > We need to slowly move a plugin at a time, keep their current APIs, and > methodically move to the next API. > > Anything that does not fit: don't move it out. We'll deal w/ it later. It > looks like everything 'with specs' can be moved with relative ease. Start > there. Worry about the rest when you get there. I suspect that is plenty to > try to achieve in the meantime. > > > > On Fri, Apr 5, 2013 at 12:51 PM, Joe Bowser <bows...@gmail.com> wrote: > > > On Fri, Apr 5, 2013 at 12:34 PM, Max Woghiren <m...@chromium.org> wrote: > > > > > > In Android, I've split out common File code into a FileHelper class. > > It's > > > not a plugin, and will be exposed to developers. This is the only > > > shared-code example I know of, but if we find others (via the > visibility > > > removal test), we can similarly pull out the common code. > > > > > > > There's a lot of code that's meant to be public on CordovaWebView, > > since CordovaWebView is supposed to be a stand-alone component that's > > embeddable in other Android projects. We really need to decide what > > to expose. I also want to see DroidGap paired down and gone, since I > > don't want people messing with anything in that class at all. > > > > Other than that, I can't think of any Android code that should be > > public. That being said, I think we're getting off-topic. I think we > > need to start on the dreaded API audit that we've been putting off. > > It's clear that every plugin will need to be updated to the new spec > > before we do this exercise. > > >
