What or where exactly is the deprecation policy? It's probably not semver<http://semver.org/>, because breaking changes need a major version update in semver. Hence, breaking these plugins would require 4.0, not 3.1. But I guess this is just not how you have set it up.
On Tue, Jul 16, 2013 at 1:15 AM, Andrew Grieve <agri...@chromium.org> wrote: > On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux <b...@brian.io> wrote: > > > A package namespace is not a part of the API? Are we saying we in > > Cordova draw the semantic line at a method signature? (Its certainly > > not a normal view on what defines an API. Anyhow! Super not > > important.) > > > > One more time! Specifics. What packages are changing in precisely what > > files? Right now we're discussing a completely undefined scope in > > light of an obviously standard best practice. > > > > > > > > On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve <agri...@chromium.org> > > wrote: > > > -1 to shims. A plugin's java package name shouldn't be considered a > part > > of > > > its API. That's why there is a mapping in the config.xml. > > > > > > Shouldn't have to change any require() statements, or any JS at all. > > Those > > > use plugin IDs, not java namespaces. > > > > > > Replace-all on the package statement at the top of the file, and change > > the > > > reference in plugin.xml. I'd put this change in the "polish" category. > > > That's what we should be doing now, no? > > > ^^ this is the specifics. pkg stmts for plugin files + refs in plugin.xml. > This is different from the phonegap->cordova change because a) no core > files are changed and b) we've already changed the pkg name by adding > ".core" > > > > > > > > > > > > > > > > > On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj <f...@adobe.com> wrote: > > > > > >> +1 wait until 3.1. > > >> > > >> +1 add shims for less breakage > > >> > > >> Also worth pointing out that we'll need to add this to the deprecation > > >> list on the wiki > > >> > > >> On 7/15/13 11:30 AM, "Simon MacDonald" <simon.macdon...@gmail.com> > > wrote: > > >> > > >> >The reason things broke back then was we didn't leave in shims to > point > > >> >anyone compiling against com.phonegap.api to org.apache.cordova.api. > > That > > >> >was quickly corrected. > > >> > > > >> >I agree with the package name change but with 3.0 shipping this > > week(?). > > >> >It > > >> >should probably wait until the next version. > > >> > > > >> > > > >> >Simon Mac Donald > > >> >http://hi.im/simonmacdonald > > >> > > > >> > > > >> >On Mon, Jul 15, 2013 at 2:07 PM, Brian LeRoux <b...@brian.io> wrote: > > >> > > > >> >> No. You are proposing an API change. A package is most certainly a > > >> >> part of the API! When we moved from `com.phonegap` to `org.apache` > > >> >> there was a huge outcry b/c it broke all existing community > plugins. > > >> >> > > >> >> I'm completely open to changing stuff for 3.0 but, again, what > > >> >> specifically are you proposing we change? > > >> >> > > >> >> > > >> >> > > >> >> On Mon, Jul 15, 2013 at 10:43 AM, Anis KADRI <anis.ka...@gmail.com > > > > >> >>wrote: > > >> >> > I agree. The only downside I see is that it will be hard to > > dissociate > > >> >> core > > >> >> > plugins from other but I don't think it's really that important. > > Also > > >> >> > because it's not a giant change it could happen for 3.0. > > >> >> > > > >> >> > > > >> >> > On Mon, Jul 15, 2013 at 10:33 AM, Max Woghiren < > m...@chromium.org> > > >> >> wrote: > > >> >> > > > >> >> >> I'm not proposing any API changes in this email; example (1) > does > > >> >> mention > > >> >> >> the relocation of FileHelper.java, but that's more to illustrate > > the > > >> >> >> benefits of repackaging the plugins. > > >> >> >> > > >> >> >> I would think the plugin package change should happen *for* 3.0, > > >> >>before > > >> >> >> people actually start using the plugins all bundled in one > > package. > > >> >> It's > > >> >> >> not a giant change. > > >> >> >> > > >> >> >> On Mon, Jul 15, 2013 at 1:16 PM, Brian LeRoux <b...@brian.io> > wrote: > > >> >> >> > > >> >> >> > I think all of this makes good sense but will have to land > > sometime > > >> >> >> > post 3.0 as that we're pretty much in the final stretch now > > anyhow. > > >> >> >> > Which APIs are you specifically proposing we change? > > >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > On Mon, Jul 15, 2013 at 9:14 AM, Max Woghiren < > > m...@chromium.org> > > >> >> wrote: > > >> >> >> > > On Android, all Cordova plugins are in the package > > >> >> >> > org.apache.cordova.core. > > >> >> >> > > It makes sense to put each plugin into its own package. > > Aside > > >> >>from > > >> >> >> > 3.0's > > >> >> >> > > conceptual shift into "plugins as completely individual > > entities" > > >> >> and > > >> >> >> the > > >> >> >> > > fact that plugins aren't really "core", here's some > rationale: > > >> >> >> > > > > >> >> >> > > 1. If two plugins have a file with the same name, we'll > > avoid > > >> >> >> > > collisions. For instance, core Cordova has > > FileHelper.java. > > >> >> This > > >> >> >> is > > >> >> >> > the > > >> >> >> > > wrong place for it in 3.0 and we'd like to move it to the > > >> >>plugins > > >> >> >> > that use > > >> >> >> > > it (removing unused methods in each plugin's version). > > >> >>However, > > >> >> >> this > > >> >> >> > will > > >> >> >> > > lead to a collision in apps that use two of these > plugins, > > >> >>since > > >> >> >> > they'll > > >> >> >> > > both be in the same package. > > >> >> >> > > 2. All plugin files will be separated into their packages > > in > > >> >>your > > >> >> >> IDE. > > >> >> >> > > This makes working on an individual plugin easier‹you > can > > see > > >> >> the > > >> >> >> > > associated files at a glance. If I'm working on a plugin > > with > > >> >> >> > multiple > > >> >> >> > > files, I shouldn't have to hunt for related files to > ensure > > >> >>I'm > > >> >> not > > >> >> >> > missing > > >> >> >> > > anything. > > >> >> >> > > 3. Since our plugins will be used as starting points for > > >> >> third-party > > >> >> >> > > plugins, we won't accidentally encourage plugin > developers > > to > > >> >>use > > >> >> >> the > > >> >> >> > same > > >> >> >> > > namespace. > > >> >> >> > > > > >> >> >> > > I would propose something like > > >> >> org.apache.cordova.plugin.<plugin_name>. > > >> >> >> > > > >> >> >> > > >> >> > > >> > > >> > > >
