Version 1.3.0

[emcniece]

• Minor version bump includes new reInit() method from v1.2.9
• [iOS] Added close() callback (#53 as per #52)
• [iOS] Added stop() callback (#55)

TODO

• [x] Create & link @ionic-native/zeroconf PR added
• [x] Tag master after merging this PR
• [x] npm publish

[emcniece]

In hindsight, the reInit() merge should have been v1.3.0 (minor bump, non-backward-compatible) and the callbacks should have incremented to v1.3.1 (patch, backward-compatible). Apologies.

[becvert]

what about you remove 1.2.9 in the changelog and put reInit with the callbacks in 1.3.0? release 1.2.9 won't exist anyway as a tag nor on npm

[emcniece]

Sounds good - modified the changelog.

[becvert]

I've been thinking a bit more about this: instead of a reInit that destroys everything, couldn't we just reset the network interfaces and re-publish/re-watch the services on the new addresses seamlessly? or do you think it's better that that's the responsability of the app to re-register its services?

[emcniece]

Explicit methods (or "less magic") might be a better path for implementation - exposing lower-level calls and building on top can allow for flexibility either way.

For example, perhaps reInit() exists now and in the future we could add a reWatchOnNetChange = true option.

JmDNS does this in a way - they have an (experimental) JmmDNS class that "will monitor network topology changes, and will create or destroy JmDNS instances as required." They also note that it is the app developer's responsibility to manage these JmDNS instances.

The reInit() method is really just the first step in this process. Re-watching the existing service types could be a nice extra feature, but I can imagine a case in which an app may want to watch for different services.

[becvert]

I'll let you tag 1.3.0 then I'll publish on npm

[emcniece]

Merged & tagged!

[becvert]

published on npm. good job!