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 <[email protected]> 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 <[email protected]> wrote: > > > On Mon, Jul 28, 2014 at 1:36 PM, Peter Metz <[email protected]> > 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 > <[email protected]> >
