Release 1.2.0

[pankajastro]

No description provided.

[pankajkoti]

qq on whether these breaking changes call for a major semver release? or if it's possible to avoid having breaking changes?

[dwreeves]

My $0.02 is they are extremely minor breakages that will impact almost no users. I hesitate to even call attention to them; I am just very thorough.

Also, this is outdated and no longer true:

For users using the sync hook directly to call either get_sync_status or call_and_restart, they will experience breakage if they are using reschedule_time=

We resolved this by adding a (deprecated) kwarg to each of those methods.

---

The changes in #58 would certainly constitute a major version bump, though, if that gets merged before the release. (Working on resolving that right now, sorry for delays.)

[dwreeves]

To clarify:

• I cannot imagine any users setting reschedule_time=0 and also relying on the default behavior of not actually waiting 0 seconds.
• I cannot imagine any users relying on the return value of prep_connector, which was always True, unless they misunderstood it to sometimes return False and used its truthiness to do something.
• Same as above for check_connector, which originally returned True always.

These really do seem to constitute minor changes, in my eyes. These are changes that are relatively deep in the API, with return values changing that had no real use anyway. The only high-level-API-facing change was to make a 0 default into a None default so that the 0 could mean sleep(0). Even that is not especially consequential of a change in the very rare event a user would be impacted; it would just mean that manual resyncs get rescheduled faster than normal, and it could even have been what the user originally intended if they were explicitly setting it!

[pankajastro]

closing in favour of #67