On Tue, Jul 9, 2013 at 11:06 PM, Joe Bowser <[email protected]> wrote:
> We're already going to have a heavy backlash from users who find that > their old Cordova plugins that are using the old Plugin API that we > had to shim in for 2.x are no longer going to work, this will > literally be more salt on those wounds. > > No -- I think it would be far worse to have to tell all of the people who work hard to get their pluguns working under 3.0.0, who in good faith follow all of our instructions and documentation *after* that documentation is finalized, that everything will break again in 3.1. *That* is more salt in the wounds. *That* will lead to less developer confidence that things won't break again for 3.2, and 3.3. Having one additional thing to change for a major release version is much easier, especially if there are already breaking changes that plugin developers will have to account for. > If someone wants to be the face of these change in the community, I'm > OK with it. I just know that from last year, being the guy who broke > all the plugins in Cordova/PhoneGap is not the guy that you want to > be, no matter how cool your new feature is. > I'd have no problem being that guy for 3.0, and I doubt that Andrew would, either. We can justify all of the changes that have been made, in terms of their future benefits. If we wait until 3.1 to change this, though, and all of those developers have to go back and fix all of their plugins again a month after 3.0 is released, I'm going to nominate you, Joe, as "the guy" for *that* release. > Or worse, there will be the people who can't write Java at all and can't > manage to do a find/replace on it. For the record, I think I'm okay with stymieing the developers of native Java plugins for Cordova if they *can't write Java at all*. :) > Joe > > On Tue, Jul 9, 2013 at 6:33 PM, Michal Mocny <[email protected]> wrote: > > I'de have to disagree with that argument, Joe. I think Andrew did the > work > > for core plugins, and there should be no published external plugins using > > the new 3.0 plugin structure yet, right? > > > > Are we intending to not break compatibility with some hypothetical > external > > plugin dev who used a pre-release tool, yet isn't willing to a single > > string find-and-replace? Is there a even a single concrete example here, > > or is this just speculation? > > > > -Michal > > > > > > On Tue, Jul 9, 2013 at 7:22 PM, Joe Bowser <[email protected]> wrote: > > > >> This creates more work one week prior to release. If we didn't have a > >> deadline for this release, I'd be OK with it, but this means that the > >> trivial change would have to happen to all our plugins. Given the time > >> constraint, I think we shouldn't do it. > >> > >> There's also the fact that our plugin developers hate all change, no > matter > >> how reasonable it may seem. > >> > >> That's why I think this should go in 3.1 or 3.2. > >> On Jul 9, 2013 4:12 PM, "Andrew Grieve" <[email protected]> wrote: > >> > >> > :) okay, now let's see if I can convince you Joe. > >> > > >> > What I've done so far was put classes in o.a.c.api that extend the > actual > >> > implementations in o.a.c. This is a bit more annoying than I'd like, > >> > because for it work properly, most types must continue to refer to the > >> > o.a.c.api classes, or else you'll get a type errors when dealing with > >> > non-updated code that expects a o.a.c.api class. > >> > > >> > Using a separate namespace (.api) to indicate which methods are a > part of > >> > our public API has the huge draw-back of not allowing us to make use > of > >> > package-private visibility with the classes in the non-.api namespace. > >> This > >> > is my main motivation for the change. I think Java devs often assume > any > >> > symbol that is public is a part of our API, and I think that's pretty > >> > reasonable. Going forward, we should make an effort to convert public > >> > symbols to package-private symbols. This will break any plugin that is > >> > relying on the symbol, but will *not* break any plugins that are not > >> using > >> > the symbol. OTOH, a namespace change, as we're doing here, will break > all > >> > plugins. > >> > > >> > So... I'd like to do the complete namespace change now so that when > >> > we privatize symbols that we don't want to be a part of our public > API, > >> it > >> > will not break the large majority of plugins. > >> > > >> > If you're not convinced, please say why :) > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > On Tue, Jul 9, 2013 at 5:33 PM, Joe Bowser <[email protected]> wrote: > >> > > >> > > Actually, on second thought, no, let's keep the compatibility > classes > >> > > in for now. We may want to keep using this namespace post-3.0. I > >> > > think I misunderstood what was being asked. > >> > > > >> > > On Tue, Jul 9, 2013 at 2:28 PM, Joe Bowser <[email protected]> > wrote: > >> > > > On Mon, Jul 8, 2013 at 12:50 PM, Andrew Grieve < > [email protected] > >> > > >> > > wrote: > >> > > >> Want to bring this up again. > >> > > >> > >> > > >> There was a bit of discussion on the bug: > >> > > >> https://issues.apache.org/jira/browse/CB-4038 > >> > > >> > >> > > >> I've already gone ahead with creating backward-compatiblity > classes > >> in > >> > > the > >> > > >> .api namespace, but I think it would be better to just delete > them. > >> > > >> > >> > > >> Main points in favour: > >> > > >> 1. For 3.0, people will need to do some work to their plugins > >> anyways > >> > > (add > >> > > >> plugin.xml + refactor their JS into modules comes to mind) > >> > > >> 2. The change to plugins is trivial. Just replace all > occurrences of > >> > > >> "import org.apache.cordova.api" with "import org.apache.cordova". > >> > > >> > >> > > > > >> > > > I'm OK with it for now, only because we don't have the time to > >> > > > formalize the Android Plugin API. I would have liked to keep the > api > >> > > > separation but perhaps we can revisit this 3.1 or 3.2. > >> > > > >> > > >> >
