cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Metz <peter.m...@unarin.com>
Subject Re: Question About Official Plugins
Date Tue, 29 Jul 2014 22:22:18 GMT
Carlos, Jesse and Joe,


Thank you guys, loads of helpful info! I will go with the renaming as
suggested and it seems like even from the user side it won't be as painful
as I anticipated, so thanks for the additional info.

Losing control over the releases and contributions is indeed a bit of a
pain point so I'll put the idea on ice as I have very decent people to help
with contributions and testing as well anyways.


Kind regards,
Peter




On Tue, Jul 29, 2014 at 2:24 AM, Carlos Santana <csantana23@gmail.com>
wrote:

> Peter
>   Thanks for contacting the Cordova mailing list and share with us your
> project, we are excited when user's use Cordova and even more excited when
> users build Cordova plugins to share with others.
>
> Like Jesse said since the plugin is not register on the Cordova registry
> [1] there is no harm today that you name it with org.apache.codova.*
> There are plugins available in phonegap build [2] that do not have the
> apache identifier like Barcodescanner[3]
>
> [1] http://plugins.cordova.io
> [1] https://build.phonegap.com/plugins
> [2] com.phonegap.plugins.barcodescanner
>
> Since the user's of your plugin are not installing via id, and the current
> way to upgrade a plugin is to remove and then add the plugin, your users
> will not be that affected on the change in the identifier, just need to use
> 'plugin ls' to double check the id to use to rm the plugin
>
> [cordova | phonegap local] plugin rm [org.apache.cordova.ibeacon |
> com.petermetz.cordova.ble]
>
> When you decide to publish your plugin on the registry [1], you will not be
> allowed so the sooner you change the id, the less users affected.
>
> Also like Joe said, having the plugin outside ASF gives your more control
> over your project, and it's great that is open source with a Apache 2.0
> license and that you accept contributions either bug reports or pull
> requests.
>
> PS: it's rad that you are using dart to test cordova cli
>
>
>
>
>
> On Mon, Jul 28, 2014 at 4:57 PM, Joe Bowser <bowserj@gmail.com> wrote:
>
> > On Mon, Jul 28, 2014 at 1:36 PM, Peter Metz <peter.metz@unarin.com>
> wrote:
> >
> > > Hello Cordova Devs,
> > >
> > >
> > > I wrote a Cordova plugin
> > > <https://github.com/petermetz/cordova-plugin-ibeacon> which kind of
> > > accidentally ended up with an official-like plugin ID:
> > > org.apache.cordova.ibeacon.
> > > I know that's lame, and would like to state that I didn't intend to
> > > infringe any copyrights and if instructed so, will change plugin ID, no
> > > questions asked.
> > >
> > >
> > Cool.  I was working on something similar, but I wouldn't want this to be
> > in the Cordova project, because of the whole Apple/iBeacon thing.
> >
> >
> > > But before all that, please, read on!
> > >
> > > I've been advised
> > > <https://github.com/petermetz/cordova-plugin-ibeacon/issues/24>, that
> > > because of the fake-official ID, it is not possible to submit the
> plugin
> > to
> > > Phonegap Build which I never use, but would not want to leave out
> people
> > > who do, for obvious reasons.
> > >
> > > Is there even, tiny bit of chance that my plugin could become an
> official
> > > one (so it can be present on Phonegap Build), while I'm still able to
> > > commit changes to it?
> > >
> >
> > I'm going to say no here.  The reason we won't add this to the project as
> > an official plugin is because:
> >
> > 1. I'm not sure of the legal status of iBeacon
> > 2. I'm not sure of the legal status of using iBeacon on Android.  I know
> > Radius Networks did an API for it, and they still exist.
> > 3. I have no idea if BLE exists outside of Android and iOS
> > 4. I like to have people have control over their cool stuff outside the
> > project proper for as long as possible.  Once it becomes an official
> > plugin, it becomes part of the ASF project, and all the rules regarding
> > releases apply.  Right now, you own it and you can release it as much as
> > you want.  Sure, you take more legal risks, but you can release earlier
> and
> > more often than we can, without a vote.
> >
> > There are both positives and negatives to making plugins core, and I
> > honestly think that the answer at this time is no for this one.  This has
> > nothing to do with the code or the utility, but instead is more about
> > whether it's a right fit right now.
> >
> > Does anyone else have any thoughts on this?
> >
> > Joe
> >
>
>
>
> --
> Carlos Santana
> <csantana23@gmail.com>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message