ftr phonegap predates semver which is basically a reaction to ruby's globally installed package legacy
that said, its a neat system On Tue, Jul 16, 2013 at 12:22 AM, Filip Maj <f...@adobe.com> wrote: > 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>. >>> > >> >> >> > >>> > >> >> >> >>> > >> >> >>> > >> >>> > >> >>> > >>> >
