cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Plugin packages on Android
Date Tue, 16 Jul 2013 07:22:51 GMT
We definitely do not follow semver

http://wiki.apache.org/cordova/DeprecationPolicy


On 7/16/13 12:15 AM, "David Pfahler" <david@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 <agrieve@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 <agrieve@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 <fil@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.macdonald@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.kadri@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 <
>> maxw@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
<
>> > maxw@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>.
>> > >> >> >> >
>> > >> >> >>
>> > >> >>
>> > >>
>> > >>
>> >
>>

Mime
View raw message