V4 Checklist

[petermetz]

• [ ] Drop Dart VM from dependencies
• [ ] CircleCI
• [ ] Automated npm package releases https://github.com/petermetz/cordova-plugin-ibeacon/issues/392
• [ ] Double check Ionic Native compatibility. https://github.com/petermetz/cordova-plugin-ibeacon/issues/393
• [x] Start using conventional git commit messages for automated releases https://github.com/petermetz/cordova-plugin-ibeacon/pull/389
• [ ] Update the quickstart repo https://github.com/petermetz/cordova-plugin-ibeacon/issues/394
• [ ] Drop Q and underscore JS dependencies. Clarify new minimum iOS / Android versions (Promise API, ES6 support?)
• [ ] Discontinue old plugin IDs in favor of cordova-plugin-proximity https://github.com/petermetz/cordova-plugin-ibeacon/issues/390
• [ ] Migrate to Typescript https://github.com/petermetz/cordova-plugin-ibeacon/issues/391

[dopry]

Do we want do some generally planning here, then break these up into individual issues in the v4.0 milestone?

1. migrate to typescript

   Do we want to add the typescript tooling before we get CI and everything going? I like working in TS, but the extra build steps can present a challenge.

2. Drop Dart VM from depedendencie

   Is this for the testing? I've attempted to use cordova-paramedic to run the tests, but I was unsuccessful. I started on a node.js replacement for the dart script as an interim cross platform solution.

   https://github.com/dopry/cordova-plugin-ibeacon/tree/medic_tests https://github.com/dopry/cordova-plugin-ibeacon/tree/nodejs_test

3. CircleCI

   I'm happy to help with this. I use it for most of my projects. We can do a tag driven release flow. I find that usually works well.

4. Ionic Native compatability

   What are the action items here? just making sure their definitions are up to date?

5. Start using conventional git commit messages (needed for automated releases)

   already doing it for the most part. ;) There are some validators that can help with that.. here is a snippet of a circleci step I use for this. It basically checks all the commits in the tree since the last tag.

     - run:
         command: |
           LAST_TAG=`git describe --tags --abbrev=0`
           echo ${LAST_TAG}
           npx commitlint --from ${LAST_TAG}

6. Update the quickstart repo

   What is the scope? Just make sure it's up todate with latest release and has working examples for both IOS and Android?

7. Drop Q and underscore JS dependencies. Clarify new minimum iOS / Android versions (Promise API, ES6 support?)

   Do we want to make the JS updates and host OS versioning separate tasks or are these limited by the host OS webview implementations? I think we need a compatability matrix for cordova-ibeacon/android/ios versions. I think we should also consider ticking major version on upstream OS support as well as any major API changes.

[petermetz]

1. Agreed, probably more efficient to get to TS first, then hook it all up with to CircleCI.
2. Yes, the test execution scripts/tooling were written in Dart to have a cross platform way of executing them while still being as close too JS as possible (didn't want to go with Java/C# because of the latter). Nowadays the popularity of Typescript makes me think it is the safer bet on the long run and also makes it easier for people to get on board if we can write as much of the code in the same language as possible.
3. Awesome! We are in agreement.

4. First, need to double check if they still allow developers to submit new versions (I imagine they do, but better to check) so that when we release v4 with breaking API changes it doesn't cause any mayhem implicitly. Then need to finalize the v4 API (typings) Lastly, submit the new Ionic Native code.

5. Nice! I fully support the idea.
6. Yeah, the main use-case for the quick start repo is having a stable piece of code that I can refer people to in threads where they are struggling with some implementation details. It's basically documentation in the format of a working, self contained example.

7. They are dependent on each other as far as I know so we can't really separate them. https://caniuse.com/#search=promise => This comes handy, they have the matrix ready for the most part. I recommend being aggressive on dropping support for older OS versions that lost market share. If somebody is hell bent on supporting the older platforms they can just keep using the 3.x plugin. Newer major versions have to be up to date with the latest and greatest stuff.

   I think we should also consider ticking major version on upstream OS support as well as any major API changes.

   I couldn't agree more. Dropping support for a specific OS version is practically the same as a breaking API change.

[dopry]

1. I think it may be better get some CI and testing in place, then move to TS. That way we have a way to prove functional equivalency through the transition. I'd vote for 2, 3, & 5 before proceeding on typescript conversion. We could also consider pure ES6 classes and eliminate the TS->ES build step. We could still adapt the interface and S6 may have wider audience than pure TS.

2. I'll take another stab at paramedic, then the nodejs testing. It would be nice to minimize languages. It's a lot to throw dart on top of java, javascript, and obj-c.

3. First PR is in. What is the full scope of CircleCI functionality you'd like to get implemented? Linting, Testing, Packaging, Distribution?

4. I know we can make PR against the ionic native library. But we have to check out all of Ionic Native to work on just our plugin. Maybe they have a feature that can slurp in typings and docs automatically from the cordova-plugin-ibeacon repo.

5. PR is in.

6. Cool. It's low on my priority list personally. I'd like to get testing and stuff first, so defering this toward the end of the development cycle would be better for me. It'll also give me time to use it in some other apps I'm working on to explore best practices.

7. I still like trying to aim for a wide versions support. Android tends to lag out. I think right now I'm aiming to support at a minimum 7.0-8.1. We set the minimum version support of any of our consumers. Is there an easy way for app developers to support and deliver multiple versions of their Apps to different OS versions in the iTunes and Play store?

[petermetz]

I think it may be better get some CI and testing in place, then move to TS. That way we have a way to prove functional equivalency through the transition.

Works just as fine for me. Especially since we started with CircleCI just now anyway. :-)

I'd vote for 2, 3, & 5 before proceeding on typescript conversion.

👍

We could also consider pure ES6 classes and eliminate the TS->ES build step.

I love the IDE support with the type definitions, but of course it is undeniable that it's extra complexity. Will sleep more on this one. :-)

[dopry]

another point...

8. Can we update the plugin so it is always referenced as cordova-plugin-ibeacon to be more consistent with the rest of the plugin universe. It currently is installed as cordova-plugin-ibeacon and removed as com.unarin.cordova.beacon

[petermetz]

Can we update the plugin so it is always referenced as cordova-plugin-ibeacon to be more consistent with the rest of the plugin universe. It currently is installed as cordova-plugin-ibeacon and removed as com.unarin.cordova.beacon

Okay, but it has to be the other way around. The phrase ibeacon in the name is a bit unlucky because it's Apple specific and is kind of a trademarking gray area (or so I heard). How about a middle ground of cordova-plugin-proximity?

[dopry]

proximity might get into another territory, maybe go literalist? cordova-plugin-btbeacon?

[petermetz]

bt being BlueTooth?

[dopry]

bt == bluetooth, yeah.. maybe proximity is better from a discoverability perspective... Maybe just cordova-plugin-beacon? We can drop the i and I think people will get it.. proximity makes me think people might start thinking GPS and other proximity or location functionality.

[petermetz]

I wish it was that easy... :-) That one is taken: https://www.npmjs.com/package/cordova-plugin-beacon

[petermetz]

Another wrench to the machine: Geo-fencing is supported on the iOS platform. If we add it on Android too, maybe it will pass as proximity, but I'm totally open to other suggestions. Honestly, I could also live with btbeacon or blebeacon.

[ChristianMarkert]

@petermetz Dear Peter, would you be available for a quick direct support question in regard to the usage of listeing to multiple iBeacons with your plugin? Thanks for your support. Christian.

[petermetz]

@ChristianMarkert Sorry, I don't have the capacity for any consulting at the moment. I wish I could help!

[dopry]

@ChristianMarkert, feel free to reach out to me via opportunities@spry-group.com

[dopry]

@petermetz, maybe @jcmurray would be willing to yield the namespace. I'll reach out.

[dopry]

@petermetz I'm going to spin of some new issues to keep various discussions on topic.