We definitely do not follow semver http://wiki.apache.org/cordova/DeprecationPolicy
On 7/16/13 12:15 AM, "David Pfahler" <da...@excellenteasy.com> wrote: >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>. >> > >> >> >> > >> > >> >> >> >> > >> >> >> > >> >> > >> >> > >>
