Exactly. Unlike other releases, 3.0 is the only one with a firm date. I don't feel that we have the time to refactor all the plugin interfaces AND notify all our users. I think that this work will heavily conflict with the plugin breakout stuff that we're currently looking to merge back into Cordova 3.0. If we have a shot at getting this release out by the date, we should try to change as little as we can.
That's why I think this should be moved to 3.1.0 at the earliest. This is too ambitious for 3.0, imo. On Mon, Jun 24, 2013 at 10:57 AM, Andrew Grieve <agri...@chromium.org> wrote: > Here's my thinking: > > - For 3.0, we're going to do a big push to ask devs to update their > plugins, so we should put some effort into providing a clear set of > supported APIs on the Java side that they should code against. > - Right now we have a lot of public methods, and I think many of them are > only public because we have two namespaces (one with .api and one without). > - I'd like to make as many symbols non-public before new plugins come along > and start using them (e.g. PluginManager. > clearPluginObjects() shouldn't be a public API). > > Doesn't feel that last minute to me... we haven't even shipped 2.9 yet. > > > > > On Mon, Jun 24, 2013 at 11:00 AM, Joe Bowser <bows...@gmail.com> wrote: > >> Can we do this post-3.0? This change seems a bit last minute. >> On Jun 24, 2013 7:57 AM, "Andrew Grieve" <agri...@chromium.org> wrote: >> >> > On the Java side of things, there are a few files in the >> > org.apache.cordova.api namespace. >> > >> > I'd like to remove this namespace and put all Cordova classes under >> > org.apache.cordova so that we can use package-private visibility where >> > appropriate. >> > >> > For backwards compatibility, we can use the same trick of having an empty >> > class extend the moved one sitting around in the old namespace. >> > >>
